Você já estudou SELECT.

Sabe utilizar WHERE.

Já entendeu INNER JOIN e LEFT JOIN.

Consegue fazer um GROUP BY.

Talvez até tenha estudado subqueries e CTEs.

Mas então alguém apresenta uma pergunta diferente:

Quais clientes estão há mais de 90 dias sem comprar?

Você abre o editor.

Olha para a tela.

E não sabe como começar.

Nesse momento surge uma sensação bastante comum:

“Acho que ainda não sei SQL.”

Só que talvez esse não seja o problema.

Você pode conhecer os comandos.

O que ainda precisa desenvolver é outra habilidade:

transformar uma pergunta em uma sequência lógica de decisões.

E isso muda completamente a forma de aprender SQL.

Conhecer as peças não significa saber montar

Imagine alguém que conhece todas as peças de um quebra-cabeça.

Sabe identificar:

• bordas;
• cores;
• formatos;
• encaixes.

Mas quando recebe mil peças misturadas sobre uma mesa, não sabe por onde começar.

Com SQL acontece algo parecido.

Você pode conhecer:

SELECT
FROM
WHERE
JOIN
GROUP BY
ORDER BY

Mas uma pergunta de negócio não chega dizendo:

“Utilize LEFT JOIN, depois GROUP BY e aplique um filtro.”

Ela chega assim:

“Quero saber quais clientes estão parando de comprar.”

Agora não existe comando indicado.

Existe um problema.

E você precisa descobrir o caminho.

O exercício tradicional costuma esconder essa dificuldade

Observe um exercício comum de SQL:

Utilize GROUP BY para descobrir quantos pedidos cada cliente realizou.

Perceba quanta coisa já foi entregue?

Você já sabe:

• que precisa contar;
• que precisa agrupar;
• que o agrupamento é por cliente;
• e até qual comando utilizar.

O exercício é útil para aprender GROUP BY.

Mas existe uma diferença entre:

aprender a utilizar GROUP BY

e:

perceber sozinho que determinado problema precisa de agrupamento.

A segunda habilidade é muito mais próxima do trabalho real.

No trabalho ninguém pede um JOIN

Imagine que você trabalha em uma empresa e alguém pergunta:

“Quais produtos estão cadastrados, mas nunca foram vendidos?”

Provavelmente ninguém vai dizer:

“Faça um LEFT JOIN entre produto e item_pedido e filtre os registros sem correspondência.”

Você recebe apenas a pergunta.

Agora precisa pensar.

Quais produtos existem?

Onde estão os produtos vendidos?

Como essas informações se relacionam?

Precisamos manter produtos que não possuem venda?

Só depois dessas respostas aparece o LEFT JOIN.

O comando é consequência.

O problema começa antes do SELECT

Quando você trava diante de uma consulta, existe uma tendência natural de procurar imediatamente o comando.

“Será que preciso de JOIN?”

“Será que é GROUP BY?”

“Será que preciso de uma subquery?”

Mas existe uma pergunta anterior:

O que exatamente preciso descobrir?

Vamos voltar ao exemplo:

Quais clientes estão há mais de 90 dias sem comprar?

Não escreva SQL ainda.

Primeiro pense.

Precisamos dos clientes… das compras… descobrir a última compra de cada cliente.

Depois precisamos comparar essa data com uma referência.

Veja o que aconteceu.

Ainda não escrevemos uma linha de SQL.

Mas o problema já começou a ser resolvido.

Quebrar o problema reduz a dificuldade

Uma pergunta grande costuma assustar.

Então transforme-a em perguntas menores.

Em vez de:

Quais clientes estão há mais de 90 dias sem comprar?

Podemos pensar:

1. Quem são os clientes?

Tabela cliente.

2. Onde estão as compras?

Tabela pedido.

3. Como cliente e pedido se relacionam?

ID_CLIENTE.

4. O que preciso descobrir sobre cada cliente?

A data da última compra.

5. Como descubro a última data?

Agora começa a surgir a necessidade de uma agregação.

Por exemplo:

MAX(DATA_PEDIDO)

6. O que faço depois?

Comparo a última compra com o período definido.

Agora a consulta deixou de ser um grande problema.

Virou uma sequência de pequenos problemas.

É por isso que decorar mais comandos nem sempre resolve

Quando alguém trava em SQL, uma reação comum é procurar outro curso.

Ou estudar mais comandos.

Ou assistir a mais vídeos.

Mas imagine que você já conhece:

• SELECT;
• WHERE;
• JOIN;
• GROUP BY;
• HAVING;
• CASE;
• subqueries.

Adicionar mais dez comandos pode não resolver o problema.

Porque sua dificuldade talvez não seja:

“Não conheço ferramentas suficientes.”

Talvez seja:

“Não sei escolher qual ferramenta utilizar.”

São problemas diferentes.

Existe uma diferença entre reconhecer e construir

Essa diferença é muito importante.

Quando você vê uma consulta pronta e pensa:

“Ah, entendi.”

Isso é reconhecimento.

Quando recebe apenas a pergunta e consegue construir o caminho sozinho, isso é outra habilidade.

É construção.

E uma das maiores armadilhas de estudar apenas assistindo aulas é confundir essas duas coisas.

Durante uma aula, tudo parece lógico.

O professor escreve:

LEFT JOIN

E você pensa:

“Claro.”

Depois escreve:

GROUP BY

E novamente:

“Faz sentido.”

Mas quando o código desaparece e sobra apenas o problema…

vem o branco.

O teste que eu gosto de fazer

Depois de estudar um assunto, feche a aula.

Não copie a consulta.

Pegue uma pergunta parecida e tente resolver sozinho.

Por exemplo, se você acabou de estudar agrupamentos, não repita:

Quantos pedidos cada cliente realizou?

Tente:

Quantos produtos diferentes cada cliente comprou?

Ou:

Qual foi o valor médio dos pedidos de cada cliente?

Ou:

Quais clientes realizaram mais de cinco pedidos?

Agora você precisa decidir o caminho.

Esse esforço é importante.

É nele que o raciocínio começa a ser desenvolvido.

Você não precisa começar pelo código

Existe outro hábito que ajuda bastante.

Quando receber uma pergunta, escreva primeiro em português.

Por exemplo:

Quero descobrir os clientes que nunca compraram.

Depois descreva o caminho:

Preciso listar todos os clientes.

Preciso verificar se cada cliente possui algum pedido.

Preciso manter aqueles que não possuem correspondência.

Só depois transforme isso em SQL.

Você pode chegar a algo como:

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;

Agora observe.

O LEFT JOIN não apareceu porque você lembrou de uma aula.

Ele apareceu porque o problema exigia preservar todos os clientes.

Essa diferença é enorme.

Antes do SQL, eu faria três perguntas

Existe uma forma simples de começar a organizar esse raciocínio.

Antes de escrever a consulta, pergunte:

1. Qual é o contexto?

O que está acontecendo?

É uma análise de clientes?

Vendas?

Produtos?

Estoque?

Financeiro?

Entender o contexto evita começar pelo comando errado.

2. Qual é a consulta?

O que exatamente precisa ser respondido?

Não:

“Preciso fazer um JOIN.”

Mas:

“Preciso descobrir quais clientes nunca compraram.”

A pergunta precisa estar clara.

3. Quais são as conexões?

Onde estão as informações necessárias?

Quais tabelas participam?

Como elas se relacionam?

Qual é a granularidade dos dados?

Quando essas três coisas ficam claras, escrever o SQL tende a ficar muito mais simples.

Contexto. Consulta. Conexões.

Esse é o raciocínio por trás do SQL 3C.

SQL começa no raciocínio, não no SELECT

Essa frase resume boa parte do problema.

Quando você começa pelo SELECT, está tentando escrever antes de decidir o que precisa ser escrito.

É parecido com abrir um aplicativo de GPS e começar a dirigir antes de informar o destino.

Você tem a ferramenta.

Tem o carro.

Sabe dirigir.

Mas ainda não definiu para onde está indo.

No SQL, a pergunta é o destino.

Os comandos são apenas o caminho.

Como saber se seu raciocínio está evoluindo?

Existe um sinal interessante.

Você começa a fazer perguntas antes de escrever.

Alguém pede:

“Quero os melhores clientes.”

E você não abre imediatamente o editor.

Você pergunta:

Melhores em quê?

Maior faturamento?

Frequência?

Maior ticket médio?

Maior quantidade de produtos comprados?

Perceba que isso já é SQL.

Mesmo sem escrever código.

Você está definindo corretamente o problema.

O analista mais experiente nem sempre começa mais rápido

Isso pode parecer estranho.

Quem está começando costuma tentar escrever imediatamente.

Quem tem mais experiência muitas vezes passa alguns minutos investigando.

Olha as tabelas.

Confere relacionamentos.

Valida a pergunta.

Entende a granularidade.

Só depois escreve.

Por isso, velocidade para começar não significa necessariamente domínio.

Às vezes, pensar cinco minutos antes economiza meia hora corrigindo uma consulta construída sobre uma interpretação errada.

Faça este exercício

Pegue a seguinte pergunta:

Quais clientes compraram mais de R$ 1.000 no último mês?

Não escreva SQL.

Primeiro responda:

1. Qual é o contexto?
2. Qual é exatamente a pergunta?
3. Quais informações precisamos?
4. Em quais tabelas elas provavelmente estão?
5. Como essas tabelas se relacionam?
6. Precisamos filtrar alguma coisa?
7. Precisamos agrupar?
8. O que cada linha do resultado deve representar?

Depois disso, tente escrever a consulta.

Você provavelmente perceberá que ela ficou muito menos assustadora.

O objetivo não é parar de consultar documentação

Existe uma ideia equivocada de que ficar bom em SQL significa lembrar tudo de cabeça.

Não significa.

Profissionais experientes pesquisam documentação.

Consultam sintaxe.

Testam funções.

Verificam recursos específicos do banco.

Isso é normal.

O que muda com a experiência é outra coisa.

Você pode não lembrar exatamente a sintaxe.

Mas sabe o que precisa fazer.

E isso torna muito mais fácil encontrar a resposta.

Conclusão

Se você conhece vários comandos SQL, mas ainda trava quando precisa construir uma consulta sozinho, talvez não precise estudar mais sintaxe agora.

Talvez precise praticar uma habilidade diferente:

raciocínio.

Aprender a:

• interpretar a pergunta;
• dividir o problema;
• identificar as informações;
• entender os relacionamentos;
• escolher a estratégia;
• validar a resposta.

Depois disso, os comandos começam a ocupar o lugar certo.

Eles deixam de ser o objetivo.

E passam a ser ferramentas.

Por isso existe uma ideia que eu repito bastante:

SQL começa no raciocínio, não no SELECT.

Quando isso fica claro, aprender SQL muda completamente.

Próximo passo

Se você sente que conhece alguns comandos, mas ainda não consegue organizar sozinho o caminho de uma consulta, eu criei um material justamente para trabalhar essa primeira etapa.

É o Guia SQL 3C + 12 Consultas Essenciais.

Nele, você aprende a olhar primeiro para Contexto, Consulta e Conexões e depois levar esse raciocínio para consultas essenciais do dia a dia.

A proposta não é colocar mais comandos na sua cabeça.

É ajudar você a entender o que fazer com os comandos que já está aprendendo.

Porque antes de escrever uma query melhor, você precisa aprender a pensar melhor sobre o problema.

Link: https://blogdosql.com.br/guia-sql-3c/