Tenho um teste simples para você.

Pegue uma consulta SQL que você escreveu recentemente.

Pode ser uma query com:

• JOIN;
• GROUP BY;
• subquery;
• CTE;
• Window Function.

Agora feche o editor.

Não olhe para o código.

E responda:

O que essa query faz?

Não vale dizer:

“Primeiro tem um SELECT, depois faço um INNER JOIN, depois tem um GROUP BY…”

Tente explicar o raciocínio.

Parece um exercício simples.

Mas ele pode revelar bastante sobre como você está aprendendo SQL.

Explicar o código não é explicar a solução

Imagine uma consulta que identifica os produtos com maior faturamento.

Uma explicação poderia ser:

“Eu faço INNER JOIN entre pedido, item_pedido e produto. Depois utilizo SUM(), faço GROUP BY e ordeno com ORDER BY DESC.”

Tecnicamente, essa descrição pode estar correta.

Mas ela explica o código.

Não necessariamente o raciocínio.

Uma explicação diferente seria:

“Primeiro preciso relacionar cada venda ao produto vendido. Depois calculo quanto cada produto gerou de faturamento. Por fim, ordeno os resultados do maior para o menor para identificar os produtos mais relevantes.”

Agora temos uma história.

Mesmo uma pessoa que não conhece SQL consegue entender o que estamos fazendo.

Esse teste mostra se você entendeu o problema

Quando você depende do código para explicar a solução, pode existir um sinal de alerta.

Talvez você tenha aprendido uma sequência parecida com:

SELECT
JOIN
GROUP BY
ORDER BY

e esteja repetindo essa estrutura.

Mas quando entende o problema, consegue explicar antes mesmo de escrever SQL.

Por exemplo:

Quais clientes nunca fizeram um pedido?

Antes da query, podemos raciocinar:

Preciso começar pelos clientes, porque quero considerar todos eles.

Depois preciso verificar quais possuem pedidos.

Por fim, mantenho apenas aqueles para os quais nenhum pedido foi encontrado.

A consulta vem depois.

O raciocínio já existe.

Tente explicar sua query em português

Essa é uma prática que recomendo bastante para quem está começando.

Antes de escrever:

SELECT
    C.ID_CLIENTE,
    C.NOME
FROM cliente C
LEFT JOIN pedido P
    ON C.ID_CLIENTE = P.ID_CLIENTE
WHERE P.ID_PEDIDO IS NULL;

escreva:

• Quero considerar todos os clientes.
• Preciso procurar pedidos relacionados a cada um.
• Mesmo quando não existir pedido, o cliente precisa continuar no resultado.
• Depois mantenho apenas os clientes sem pedido encontrado.

Agora fica muito mais fácil perceber por que usamos:

LEFT JOIN

e não simplesmente decorar:

“Para encontrar registros sem correspondência, use LEFT JOIN.”

Isso também ajuda quando a query dá errado

Imagine uma consulta grande.

Ela não retorna o que você esperava.

Se você enxerga apenas código, começa a alterar coisas:

• Troca o JOIN.
• Move o WHERE.
• Adiciona DISTINCT.
• Muda o GROUP BY.

E torce para funcionar.

Esse é um hábito perigoso.

Uma alternativa melhor é voltar ao raciocínio.

• O que cada etapa deveria produzir?
• Qual tabela deveria ser meu ponto de partida?
• O que cada linha representa neste momento?
• Em qual etapa o resultado começou a ficar diferente do esperado?

Quando você consegue explicar a lógica, também fica mais fácil depurar a consulta.

Cuidado com o DISTINCT que “resolve”

Esse é um bom exemplo.

Você faz alguns JOINs.

O resultado aparece duplicado.

Então coloca:

DISTINCT

As duplicidades desaparecem.

Problema resolvido?

Talvez.

Ou talvez você apenas tenha escondido o problema.

Antes de utilizar DISTINCT, seria melhor conseguir explicar:

Por que essas linhas estão se repetindo?

Talvez exista uma relação de um para muitos.

Ou talvez cada pedido tenha vários itens.

Talvez a granularidade tenha mudado.

Se você entende a causa, consegue decidir se DISTINCT realmente faz sentido.

Se não entende, está apenas tentando fazer o resultado parecer correto.

Saber explicar também ajuda na entrevista

Imagine que alguém apresente uma consulta e pergunte:

“Por que você utilizou LEFT JOIN aqui?”

Existem duas respostas.

A primeira:

“Porque era necessário para a query funcionar.”

A segunda:

“Porque preciso manter todos os clientes no resultado, inclusive aqueles que não possuem pedidos relacionados.”

A segunda resposta demonstra algo diferente.

Não apenas conhecimento da sintaxe.

Demonstra entendimento da decisão.

E isso vale para praticamente qualquer recurso SQL.

Faça três perguntas para sua query

Quando terminar uma consulta, tente responder:

1. O que estou tentando descobrir?

Explique em uma frase.

2. Por que escolhi esse caminho?

Explique os relacionamentos, filtros e cálculos principais sem citar comandos.

3. O que cada linha do resultado representa?

Um cliente?

Um pedido?

Um produto?

Um mês?

Essa terceira pergunta é especialmente importante.

Se você não sabe o que cada linha representa, existe uma boa chance de também não estar completamente seguro sobre agregações, contagens e duplicidades.

Você não precisa explicar cada linha do código

O objetivo não é decorar sua query.

É quase o contrário.

Uma boa explicação pode ser muito mais simples do que o código.

Uma consulta de 40 linhas pode representar algo como:

“Calculo o faturamento mensal de cada categoria, comparo com o mês anterior e identifico onde houve queda.”

Pronto.

Depois, se alguém quiser entender detalhes, você aprofunda.

Mas primeiro precisa existir clareza sobre o problema e sobre o caminho.

Um exercício para hoje

Pegue uma query antiga sua.

Feche o editor.

E escreva em português:

O problema:

O que preciso descobrir:

Quais dados preciso:

Como esses dados se conectam:

O que cada linha do resultado representa:

Como vou validar:

Depois abra a consulta novamente.

Veja se o código realmente representa aquilo que você escreveu.

Você pode se surpreender.

Talvez encontre um JOIN desnecessário.

Um filtro colocado no lugar errado.

Uma agregação que não representa exatamente a pergunta.

Ou talvez confirme que a consulta está muito bem construída.

Nos dois casos, o exercício valeu a pena.

Conclusão

Aprender SQL não é apenas chegar ao resultado.

Também é entender por que aquele resultado foi produzido.

Se você consegue olhar para uma consulta e explicar:

qual problema ela resolve;

quais dados precisa;

como as informações se relacionam;

e o que o resultado representa;

então existe raciocínio por trás do código.

Por isso, de vez em quando faça o teste:

Feche o editor.

E tente explicar sua query sem mostrar uma única linha de SQL.

Se você consegue fazer isso com clareza, existe uma boa chance de não estar apenas escrevendo comandos.

Você está entendendo o que está fazendo.

Próximo passo

A Coleção SQL Sem Medo foi criada justamente para ajudar a destravar três pontos em que muitos iniciantes começam a perder esse entendimento: JOIN, GROUP BY e Subqueries.

A proposta não é decorar estruturas prontas.

É entender o raciocínio por trás delas para conseguir decidir quando cada recurso faz sentido.

Porque uma boa pergunta para seu SQL não é apenas:

“Essa query funciona?”

Pergunte também:

“Eu consigo explicar por que ela funciona?”

Link: https://sqlsemmedo.com.br/

Tags: Banco de Dados | Mentalidade | SQL