Depois que aprendemos JOIN, é comum acreditar que ele resolve praticamente tudo.

Na maioria dos casos, realmente resolve.

Mas chega um momento em que aparece outra palavra-chave.

EXISTS.

E então surge a dúvida.

“Se consigo fazer isso com JOIN, por que EXISTS existe?”

Essa é uma excelente pergunta.

Porque mostra que você começou a perceber que existem diferentes maneiras de resolver o mesmo problema.

Antes de comparar comandos, compare objetivos

Imagine que seu gerente faça a seguinte pergunta:

“Quais clientes já realizaram pelo menos um pedido?”

Perceba uma coisa importante.

Ele não perguntou:

• quantos pedidos existem;
• qual foi o primeiro pedido;
• qual foi o último pedido.

Ele quer apenas saber se o cliente possui pelo menos um pedido.

Essa diferença muda completamente a forma como pensamos na consulta.

Resolvendo com INNER JOIN

Uma solução bastante comum seria:

SELECT DISTINCT
  c.ID_CLIENTE,
  c.NOME
FROM cliente c
INNER JOIN pedido p
  ON c.ID_CLIENTE = p.ID_CLIENTE;

Essa consulta funciona.

Mas observe um detalhe.

O INNER JOIN combina registros das duas tabelas.

Se um cliente possui dez pedidos, dez combinações serão produzidas antes do DISTINCT eliminar as repetições.

O resultado final fica correto.

Mas esse não era exatamente o objetivo.

Agora utilizando EXISTS

Outra forma de responder à mesma pergunta é:

SELECT
  c.ID_CLIENTE,
  c.NOME
FROM cliente c
WHERE EXISTS (
  SELECT
    1
  FROM pedido p
  WHERE p.ID_CLIENTE = c.ID_CLIENTE
);

Perceba a mudança de raciocínio.

Não estamos interessados nos pedidos.

Queremos apenas verificar se eles existem.

E é exatamente isso que o EXISTS faz.

A principal diferença

O INNER JOIN responde perguntas como:

“Quais registros estão relacionados?”

Já o EXISTS responde perguntas como:

“Existe pelo menos um registro relacionado?”

Parece uma diferença pequena.

Mas muda completamente a intenção da consulta.

Quando o INNER JOIN faz mais sentido?

Utilize INNER JOIN quando você realmente precisa das informações da outra tabela.

Por exemplo:

• data do pedido;
• valor;
• produto;
• quantidade.

Nesses casos, faz sentido trazer essas informações para o resultado.

Quando EXISTS costuma ser uma boa escolha?

Quando a única pergunta é:

Existe?

Exemplos:

• Clientes que já compraram.
• Produtos que possuem estoque.
• Funcionários que participaram de um treinamento.
• Alunos que entregaram uma atividade.

Você não precisa das informações relacionadas.

Precisa apenas confirmar sua existência.

O erro mais comum

Muitos iniciantes escolhem a abordagem porque foi a primeira que aprenderam.

Pensam assim:

“Se dá para fazer com JOIN, vou usar JOIN.”

Mas um analista normalmente faz outra pergunta.

“Qual consulta representa melhor o problema que preciso resolver?”

Essa mudança de mentalidade faz muita diferença.

E quanto à performance?

Essa é uma dúvida frequente.

A resposta é:

depende.

Os bancos de dados modernos possuem otimizadores muito eficientes.

Em muitos cenários, consultas diferentes acabam gerando planos de execução bastante semelhantes.

Por isso, antes de escolher pensando apenas em desempenho, vale mais a pena pensar em clareza.

Uma consulta fácil de entender costuma ser muito mais simples de manter.

Se houver necessidade de otimização, ela deve ser baseada em testes e análise do plano de execução — não apenas na escolha entre JOIN e EXISTS.

Como decidir?

Sempre que surgir essa dúvida, faça duas perguntas.

Eu preciso trazer informações da outra tabela?

Se sim…

Provavelmente um INNER JOIN faz sentido.

Eu só preciso saber se existe relacionamento?

Se sim…

Considere utilizar EXISTS.

O que você aprendeu?

Este artigo não teve como objetivo ensinar um comando novo.

O objetivo foi mostrar que SQL não é apenas escrever consultas que funcionam.

Também é escolher a abordagem que melhor representa o problema que você está tentando resolver.

Esse tipo de decisão faz parte da evolução de qualquer profissional que trabalha com bancos de dados.

Continue investigando…

Agora tente responder estas perguntas.

• Quais produtos possuem pelo menos uma venda?
• Quais vendedores nunca realizaram uma venda?
• Quais clientes possuem mais de cinco pedidos?
• Em quais situações um LEFT JOIN faria mais sentido do que um EXISTS?

Responder essas perguntas é um excelente exercício para desenvolver raciocínio.

Próximo passo

Ao longo da Coleção A Arte da Query, você encontra diversos problemas de negócio que podem ser resolvidos de maneiras diferentes.

Mais do que aprender comandos isolados, o foco é desenvolver a capacidade de escolher a solução mais adequada para cada situação, entendendo o motivo de cada decisão.

Porque aprender SQL não é decorar que existe INNER JOIN ou EXISTS.

É saber quando cada um deles faz sentido.

Link: https://artedaquery.com.br/