Imagine que você trabalha em um e-commerce.

Seu gerente pede um relatório mostrando a quantidade de pedidos realizados por cada cliente.

Você consulta o banco e entrega algo parecido com isto:

Tecnicamente, a informação está correta.

Mas então o gerente faz outra pergunta:

“Tá… mas quais desses clientes são novos e quais já são recorrentes?”

Agora o problema mudou.

Não queremos apenas recuperar um número do banco.

Queremos interpretar esse número.

E é exatamente nesse tipo de situação que o CASE WHEN começa a fazer sentido.

Antes do CASE, existe uma regra de negócio

Um erro comum de quem está aprendendo SQL é conhecer o CASE e sair procurando situações para utilizá-lo.

Eu prefiro fazer o caminho contrário.

Primeiro precisamos definir a regra.

Imagine que a empresa considere:

• cliente sem pedidos → SEM COMPRA;
• cliente com 1 pedido → NOVO;
• cliente com 2 ou mais pedidos → RECORRENTE.

Agora temos algo importante.

Não temos apenas dados.

Temos uma regra de negócio.

E só agora faz sentido pensar no SQL.

Quais dados precisamos?

Vamos imaginar duas tabelas.

A tabela cliente:

cliente
----------------
ID_CLIENTE
NOME

E a tabela pedido:

pedido
----------------
ID_PEDIDO
ID_CLIENTE
DATA_PEDIDO
VALOR_TOTAL

Nosso objetivo é retornar cada cliente, contar seus pedidos e classificá-lo de acordo com a regra definida anteriormente.

Como um analista pensaria?

Antes de abrir o editor, podemos dividir o problema.

1. Quem precisa aparecer?

Todos os clientes.

Inclusive quem nunca comprou.

2. Onde estão os pedidos?

Na tabela pedido.

3. Como relacionamos as duas tabelas?

Por meio de ID_CLIENTE.

4. O que precisamos calcular?

A quantidade de pedidos por cliente.

5. O que faremos com esse resultado?

Transformaremos a quantidade em uma classificação.

Perceba que praticamente montamos a consulta sem escrever SQL.

Agora o código passa a ser consequência do raciocínio.

Primeiro: contando os pedidos

Podemos começar assim:

SELECT
c.ID_CLIENTE,
c.NOME,
COUNT(p.ID_PEDIDO) AS TOTAL_PEDIDOS
FROM cliente c
LEFT JOIN pedido p
ON c.ID_CLIENTE = p.ID_CLIENTE
GROUP BY
c.ID_CLIENTE,
c.NOME;

Existe um detalhe importante nessa consulta.

Utilizamos LEFT JOIN.

Por quê?

Porque queremos que clientes que nunca realizaram pedidos também apareçam.

Se utilizássemos INNER JOIN, esses clientes desapareceriam do resultado.

Agora temos dados. Falta interpretação.

Imagine que a consulta retorne:

O banco respondeu corretamente.

Mas ainda precisamos transformar esses números na classificação definida pelo negócio.

É aqui que entra o CASE WHEN.

Utilizando CASE WHEN

Podemos evoluir a consulta:

SELECT
c.ID_CLIENTE,
c.NOME,
COUNT(p.ID_PEDIDO) AS TOTAL_PEDIDOS,
CASE
WHEN COUNT(p.ID_PEDIDO) = 0 THEN 'SEM COMPRA'
WHEN COUNT(p.ID_PEDIDO) = 1 THEN 'NOVO'
ELSE 'RECORRENTE'
END AS CLASSIFICACAO_CLIENTE
FROM cliente c
LEFT JOIN pedido p
ON c.ID_CLIENTE = p.ID_CLIENTE
GROUP BY
c.ID_CLIENTE,
c.NOME;

Agora nosso resultado passa a ter significado para o negócio:

Foi isso que o CASE nos permitiu fazer.

Transformamos valores em categorias.

Entendendo o CASE por partes

Observe este trecho:

CASE
WHEN COUNT(p.ID_PEDIDO) = 0 THEN 'SEM COMPRA'
WHEN COUNT(p.ID_PEDIDO) = 1 THEN 'NOVO'
ELSE 'RECORRENTE'
END

Podemos ler praticamente como português.

CASE

Vamos avaliar algumas condições.

WHEN

Quando determinada condição for verdadeira…

THEN

…retorne determinado valor.

ELSE

Se nenhuma condição anterior for verdadeira…

…retorne este outro valor.

END

Fim da expressão.

Não precisa decorar como uma fórmula.

Tente enxergar como uma sequência de decisões.

A ordem das condições importa

Esse detalhe merece atenção.

Imagine outra classificação:

• até 1 pedido → INICIANTE;
• de 2 a 5 → EM DESENVOLVIMENTO;
• acima de 5 → RECORRENTE.

Podemos escrever:

CASE
WHEN COUNT(p.ID_PEDIDO) <= 1 THEN 'INICIANTE'
WHEN COUNT(p.ID_PEDIDO) <= 5 THEN 'EM DESENVOLVIMENTO'
ELSE 'RECORRENTE'
END

O SQL testa as condições na ordem.

Quando encontra a primeira verdadeira, retorna o resultado correspondente.

Isso significa que a ordem das regras precisa fazer sentido.

O CASE não serve apenas para clientes

Agora começa a parte interessante.

Depois que você entende o raciocínio, percebe que esse padrão aparece o tempo todo.

Podemos classificar produtos:

CASE
WHEN ESTOQUE = 0 THEN 'SEM ESTOQUE'
WHEN ESTOQUE <= 10 THEN 'ESTOQUE BAIXO'
ELSE 'ESTOQUE NORMAL'
END

Classificar pedidos:

CASE
WHEN VALOR_TOTAL < 100 THEN 'BAIXO'
WHEN VALOR_TOTAL < 500 THEN 'MÉDIO'
ELSE 'ALTO'
END

Classificar vendedores.

Clientes.

Fornecedores.

Regiões.

Contratos.

Atendimentos.

O comando continua sendo o mesmo.

O que muda é a regra de negócio.

E aqui existe um cuidado importante

Imagine que alguém diga:

“Clientes com cinco pedidos são clientes fiéis.”

Por quê?

Cinco pedidos significam fidelidade naquele negócio?

Talvez sim.

Talvez não.

Em um supermercado, cinco compras podem acontecer rapidamente.

Em uma concessionária, cinco compras representam uma situação completamente diferente.

Por isso o analista não deveria inventar classificações apenas porque consegue escrevê-las em SQL.

Antes do CASE, precisa existir uma definição de negócio.

Essa é uma diferença importante entre manipular dados e analisar dados.

Uma consulta correta também pode gerar uma análise errada

Esse ponto é muito importante.

Nossa consulta pode executar perfeitamente.

O CASE pode estar sintaticamente correto.

O resultado pode parecer bonito.

E ainda assim a classificação pode não fazer sentido.

Por exemplo:

WHEN COUNT(p.ID_PEDIDO) >= 2 THEN 'CLIENTE FIEL'

O SQL não sabe o que significa “cliente fiel”.

Quem define isso é o negócio.

O banco apenas aplica a regra que fornecemos.

Por isso uma das habilidades mais importantes de um analista é perguntar:

De onde veio essa regra?

CASE WHEN não cria conhecimento sozinho

O CASE é uma ferramenta.

Ele não interpreta o negócio por você.

Ele transforma uma regra previamente definida em lógica.

Podemos pensar assim:

Dado bruto

8 pedidos

↓

Regra de negócio

2 ou mais pedidos = recorrente

↓

SQL

CASE

↓

Informação

CLIENTE RECORRENTE

Essa sequência é muito mais importante do que simplesmente memorizar a sintaxe.

Como um analista pode ir além?

Depois de criar a classificação, surgem novas perguntas.

Por exemplo:

• Quantos clientes são recorrentes?
• Qual percentual nunca comprou?
• Qual grupo gera mais faturamento?
• Clientes novos estão voltando para uma segunda compra?
• O número de clientes recorrentes está aumentando?

Perceba o que aconteceu.

Uma consulta respondeu uma pergunta.

A resposta criou outras perguntas.

É assim que uma análise evolui.

Um desafio para você

Considere a seguinte regra:

• cliente sem pedido → SEM COMPRA;
• 1 pedido → NOVO;
• entre 2 e 5 pedidos → RECORRENTE;
• mais de 5 pedidos → FREQUENTE.

Tente alterar nossa consulta para produzir essas quatro classificações.

Mas antes de escrever o SQL, faça o exercício mais importante:

Escreva as regras em português.

Depois transforme cada regra em uma condição.

Só então abra o editor.

Outro desafio

Imagine agora que o gerente mudou a pergunta.

Ele não quer classificar os clientes pela quantidade de pedidos.

Quer classificá-los pelo valor total comprado.

Como você faria?

Observe que o CASE provavelmente continuará existindo.

Mas antes dele teremos que mudar nossa métrica.

Talvez utilizar:

SUM(P.VALOR_TOTAL)

É justamente esse tipo de mudança que ajuda a entender SQL de verdade.

Você deixa de pensar:

“Qual é a sintaxe do CASE?”

E começa a pensar:

“Qual informação preciso produzir?”

O que você aprendeu neste artigo?

Tecnicamente, aprendemos a utilizar:

• LEFT JOIN;
• COUNT();
• GROUP BY;
• CASE WHEN.

Mas esse não foi o principal aprendizado.

O mais importante foi entender a sequência:

Pergunta → dados → regra → consulta → informação.

Quando essa sequência fica clara, o SQL deixa de parecer um monte de comandos desconectados.

Ele começa a fazer sentido.

Conclusão

CASE WHEN é um recurso extremamente útil.

Mas não porque permite escrever consultas mais sofisticadas.

Ele é útil porque ajuda a transformar dados brutos em informações que as pessoas conseguem interpretar.

Um número pode dizer:

8

Uma regra pode transformar esse número em:

CLIENTE RECORRENTE

E essa informação pode gerar uma nova pergunta:

Quanto os clientes recorrentes representam do nosso faturamento?

É assim que uma análise começa a ganhar profundidade.

Por isso, quando você encontrar um CASE WHEN, não pense apenas:

“Qual condição preciso escrever?”

Pergunte primeiro:

Qual regra de negócio estou tentando representar?

Essa pergunta vale muito mais do que decorar a sintaxe.

Próximo passo

Se você gostou desse tipo de exercício, essa é justamente a proposta da Coleção A Arte da Query.

Em vez de começar pelo comando, você recebe cenários e perguntas de negócio que obrigam você a entender o problema, identificar os dados necessários e construir a consulta.

Porque, no trabalho real, dificilmente alguém vai chegar até você e pedir:

“Faça um CASE WHEN.”

A pergunta será muito mais parecida com:

“Você consegue separar nossos clientes em grupos para entendermos melhor o comportamento deles?”

E é nessa hora que saber SQL com propósito faz toda a diferença.

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

Tags: Banco de Dados | SQL | SQL na Prática