Imagine que você começou a trabalhar em um e-commerce.
No primeiro dia, seu gerente faz uma pergunta simples:
Quantos clientes já se cadastraram, mas nunca realizaram uma compra?
Não é uma pergunta sobre SQL.
É uma pergunta de negócio.
E é exatamente isso que um analista recebe no dia a dia.
Ninguém pede um LEFT JOIN.
Ninguém pede um IS NULL.
As pessoas fazem perguntas.
Cabe ao analista descobrir como respondê-las.
Antes do SQL, pense no problema
Antes de abrir o editor, vamos entender a situação.
Temos duas tabelas.
A primeira guarda os clientes cadastrados.
- cliente
A segunda registra os pedidos realizados.
- pedido
A pergunta é:
Quais clientes existem na tabela CLIENTE, mas não possuem nenhum registro correspondente na tabela PEDIDO?
Perceba que ainda não escrevemos uma linha de SQL.
Estamos apenas entendendo o problema.
Como um analista pensa?
Nesse momento, o raciocínio costuma seguir esta sequência.
Primeira pergunta
Quem precisa aparecer no resultado?
Resposta:
Todos os clientes.
Mesmo aqueles que nunca compraram.
Segunda pergunta
Onde descubro se o cliente realizou alguma compra?
Na tabela de pedidos.
Terceira pergunta
Como relaciono essas informações?
Pela chave do cliente.
Só depois dessas respostas começamos a escrever a consulta.
A solução
Seguindo o padrão utilizado aqui no Blog do SQL:
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;Essa consulta retorna apenas os clientes que não possuem nenhum pedido registrado.
Por que usamos LEFT JOIN?
Esse é um dos pontos que mais confundem quem está aprendendo SQL.
Muita gente tenta resolver esse problema utilizando INNER JOIN.
Mas existe um detalhe importante.
O INNER JOIN retorna apenas os registros que existem nas duas tabelas.
Neste caso, queremos justamente o contrário.
Queremos encontrar quem não possui correspondência.
Por isso utilizamos o LEFT JOIN.
Ele mantém todos os clientes no resultado.
Quando um cliente não possui pedido, as colunas da tabela PEDIDO ficam com valor NULL.
É exatamente isso que aproveitamos no filtro.
O papel do IS NULL
Depois do relacionamento, basta identificar os clientes que ficaram sem correspondência.
É por isso que utilizamos:
WHERE p.ID_PEDIDO IS NULL;Essa condição elimina todos os clientes que possuem pedidos.
Restam apenas aqueles que nunca compraram.
Esse tipo de consulta aparece o tempo todo
Embora este exemplo utilize clientes e pedidos, o mesmo raciocínio aparece em diversos cenários.
Por exemplo:
- produtos que nunca foram vendidos;
- alunos que nunca acessaram um curso;
- funcionários sem treinamentos;
- fornecedores sem contratos;
- clientes sem atendimento.
O padrão lógico é exatamente o mesmo.
Muda apenas o contexto.
O erro mais comum
Quando alguém está começando, costuma decorar a ideia de que:
“LEFT JOIN serve para trazer tudo.”
Mas isso não resolve o problema.
O importante é entender por que ele está sendo utilizado.
Neste caso, ele existe porque queremos preservar todos os clientes, inclusive aqueles que não possuem registros relacionados.
Quando você entende o motivo, deixa de decorar comandos e passa a tomar decisões.
Continue investigando…
Agora tente responder outras perguntas utilizando o mesmo banco de dados.
- Quais produtos nunca foram vendidos?
- Quais vendedores nunca realizaram uma venda?
- Quais categorias não possuem produtos cadastrados?
- Quais clientes fizeram exatamente um pedido?
Perceba que todas essas perguntas seguem o mesmo padrão lógico.
O que você aprendeu neste artigo?
Mais do que aprender LEFT JOIN, você aprendeu a transformar uma pergunta de negócio em uma consulta SQL.
Esse é o ponto mais importante.
No mercado, ninguém vai perguntar:
“Você sabe usar LEFT JOIN?”
As perguntas serão parecidas com esta:
“Você consegue descobrir quais clientes nunca compraram?”
E é exatamente aí que o SQL se torna uma ferramenta para resolver problemas reais.
Próximo passo
Esse é apenas um dos diversos cenários que utilizo na Coleção A Arte da Query.
Lá você encontra problemas semelhantes aos que aparecem no dia a dia de quem trabalha com dados, sempre partindo de uma pergunta de negócio e chegando à construção da consulta SQL.
Se o seu objetivo é deixar de decorar comandos e começar a desenvolver raciocínio, esse é o próximo passo natural.
0 Comentários