Se você já estuda SQL há um tempo, provavelmente já ouviu algo assim:
“Use JOIN, não subquery.”
“Subquery é ruim.”
“JOIN é sempre melhor.”
O problema é que esse tipo de regra solta não ajuda na hora que você mais precisa: quando está diante de um problema real e precisa decidir como resolver.
Vamos organizar isso do jeito certo.
O erro começa quando a decisão vira regra decorada
Muita gente aprende assim:
- vê exemplos de JOIN
- vê exemplos de subquery
- tenta memorizar quando usar cada um
Isso até funciona em exercícios.
Mas no trabalho real, o cenário é outro:
- a pergunta não vem pronta
- o banco é maior
- a query precisa ser lida depois
- alguém vai revisar o código
Nesse contexto, regra decorada cai rápido.
A pergunta errada: “Qual é melhor?”
JOIN e subquery não competem entre si.
Eles resolvem problemas diferentes dependendo do raciocínio.
A pergunta certa não é: “Qual é melhor?”
É: “O que eu estou tentando responder?”
Quando o JOIN faz mais sentido
JOIN funciona melhor quando:
- você quer combinar informações
- o resultado final depende de colunas de várias tabelas
- as tabelas fazem parte da mesma linha lógica de resultado
Exemplo mental (sem código ainda):
“Quero listar clientes com o total de pedidos.”
Aqui:
- cliente e pedido fazem parte da mesma resposta
- o resultado final mistura informações
JOIN tende a ser a escolha natural.
Quando a subquery faz mais sentido
Subquery funciona melhor quando:
- você precisa de um resultado intermediário
- quer filtrar ou comparar com base em um conjunto
- uma parte da lógica pode ser resolvida separadamente
Exemplo mental:
“Quero clientes que fizeram mais pedidos do que a média.”
Aqui, a média:
- não é o resultado final
- é um cálculo intermediário
- ajuda a decidir quem entra ou não
Subquery (ou CTE) costuma deixar isso mais claro.
Clareza vale mais do que “performance teórica”
Outro mito comum:
“JOIN é sempre mais performático.”
Na prática:
- bancos modernos otimizam muita coisa
- diferenças pequenas raramente são o gargalo
- query confusa custa mais do que query 5% mais lenta
Uma query clara:
- é mais fácil de revisar
- é mais fácil de ajustar
- é mais difícil de errar
E isso pesa muito mais no dia a dia.
Um bom critério simples (e prático)
Se você precisa explicar sua query para outra pessoa, pergunte a si mesmo:
- Essa parte é o resultado final?
- 👉 JOIN costuma ajudar
- Essa parte é só um critério para decidir algo?
- 👉 Subquery (ou CTE) costuma ajudar
Não é regra absoluta.
É critério de raciocínio.
O problema não é JOIN nem subquery, é escrever sem pensar
A maioria das queries ruins não é ruim porque escolheu JOIN ou subquery.
Ela é ruim porque:
- o problema não estava claro
- o resultado esperado não foi definido
- o código virou tentativa e erro
Quando o raciocínio vem primeiro, a escolha fica óbvia.
SQL bom é aquele que você entende depois
Um ótimo teste é esse:
“Se eu abrir essa query daqui a 3 meses, eu vou entender rápido o que ela faz?”
Se a resposta for não, o problema não é a sintaxe.
É a forma como o raciocínio foi organizado.
O próximo passo certo
Se você quer aprender a:
- decidir melhor entre abordagens
- escrever queries mais claras
- praticar SQL com contexto real
O próximo passo natural é praticar cenários reais, não só exemplos soltos.
É exatamente isso que a Coleção A Arte da Query propõe:
- perguntas reais
- decisões de verdade
- raciocínio antes do código
👉 Você pode conhecer a A Arte da Query aqui: 🎯 Coleção A Arte da Query
0 Comentários