Deixa eu te propor um desafio simples e muito revelador.
Olha para a query abaixo sem rodar, sem testar e sem “imaginar o resultado no chute”.
SELECT
c.ID_CLIENTE,
COUNT(p.ID_PEDIDO) AS TOTAL_PEDIDOS
FROM cliente c
LEFT JOIN pedido p
ON p.ID_CLIENTE = c.ID_CLIENTE
WHERE p.DATA_PEDIDO >= '2024-01-01'
GROUP BY c.ID_CLIENTE;Agora a pergunta é direta:
O que exatamente essa query retorna?
Antes de seguir, vale a pena parar alguns segundos e tentar responder mentalmente.
A maioria das pessoas responde rápido… e responde errado
As respostas mais comuns costumam ser algo como:
- “Lista clientes com pedidos em 2024”
- “Conta quantos pedidos cada cliente fez”
- “Mostra clientes e total de pedidos do ano”
Essas respostas parecem corretas, mas são vagas demais.
E em SQL, resposta vaga costuma esconder erro.
Vamos pensar com calma (sem SQL ainda)
Antes de falar de SELECT, JOIN ou GROUP BY, vamos raciocinar em português.
A intenção parece ser:
- listar clientes
- contar pedidos
- considerar apenas pedidos a partir de 2024
Até aqui, ok.
Agora vem a parte importante:
👉 O que acontece com clientes que NÃO têm pedidos em 2024?
Eles aparecem? Somem? Aparecem com zero?
Essa é a parte que separa quem lê código de quem entende query.
O detalhe que muda tudo está no WHERE
Repara nisso:
LEFT JOIN pedido p
ON p.ID_CLIENTE = c.ID_CLIENTE
WHERE p.DATA_PEDIDO >= '2024-01-01'Aqui acontece algo sutil e muito comum.
Apesar do LEFT JOIN, o WHERE filtra a tabela de pedidos.
Na prática, isso faz com que:
- clientes sem pedidos em 2024
- tenham
p.DATA_PEDIDO = NULL - e sejam eliminados pelo WHERE
Ou seja:
👉 Essa query NÃO retorna todos os clientes.
👉 Ela retorna apenas clientes que têm pelo menos um pedido em 2024.
O LEFT JOIN perdeu o efeito.
O que essa query realmente faz
Agora sim, com clareza:
Ela retorna o total de pedidos feitos em 2024 para cada cliente que teve pelo menos um pedido nesse período.
Clientes sem pedidos em 2024:
❌ não aparecem
❌ não aparecem com zero
❌ simplesmente somem
Por que esse tipo de erro é tão comum?
Porque muita gente:
- lê SQL como se fosse texto
- reconhece comandos
- mas não simula o efeito lógico da query
A pessoa pensa:
“Usei LEFT JOIN, então todos os clientes entram.”
Mas não verifica se o resto da query mantém essa intenção.
Ler SQL é prever o resultado — não reconhecer sintaxe
Esse tipo de desafio mostra algo importante:
👉 Saber SQL não é saber escrever.
👉 É saber prever o que vai acontecer antes de rodar.
No trabalho real, isso é essencial porque:
- você evita bugs silenciosos
- não confia só no “rodou”
- entende quando o resultado não faz sentido
Como evitar esse tipo de erro no dia a dia
Antes de rodar qualquer query, tente responder mentalmente:
- Quem entra nessa query?
- Quem fica de fora?
- O que acontece com valores nulos?
- O resultado bate com a pergunta original?
Se você não consegue responder isso com clareza, o SQL ainda não está claro.
Esse tipo de raciocínio não vem de exercício mecânico
Você não desenvolve essa leitura resolvendo lista de:
- “faça um SELECT”
- “use GROUP BY”
- “aplique um WHERE”
Isso vem de:
- parar
- ler a query com calma
- pensar no efeito lógico
- relacionar código com resultado
O próximo passo certo
Se você quer desenvolver essa habilidade de ler, prever e justificar queries, o caminho não é decorar mais regra — é organizar o raciocínio antes do código.
É exatamente isso que eu organizo no Guia SQL 3C + 12 Consultas Essenciais.
Ele te ajuda a:
- pensar antes de escrever
- evitar erros silenciosos
- ganhar confiança no que você entrega
👉 Você pode baixar o guia aqui:📘 Guia SQL 3C + 12 Consultas Essenciais
0 Comentários