O que SQL me ensinou sobre como pensar em transformação de dados
Aprendi SQL para análise, não só para CRUD. Quando descobri CTEs, GROUP BY aninhado e como compor queries, entendi que SQL é linguagem de transformação — não só de consulta.
SQL na faculdade era CRUD.
CREATE, INSERT, SELECT simples, UPDATE, DELETE. O suficiente para entender banco de dados relacional como destino de dados — onde você armazena e de onde você recupera.
Quando comecei a trabalhar com análise em projetos de pesquisa, aprendi SQL diferente: como ferramenta de transformação.
A diferença é mais profunda do que parece.
SQL como destino: você sabe o que quer armazenar, você sabe como estruturar a tabela, você escreve queries simples para recuperar exatamente o que colocou lá.
SQL como transformação: você tem dado bruto com estrutura que não serve diretamente para sua análise. Você usa SQL para remodelar — agregar, filtrar, juntar, derivar campos calculados — até o dado estar na forma que você precisa.
O segundo uso é muito mais poderoso. E é onde a maioria das pessoas para de aprender SQL antes de chegar.
O que abriu o segundo uso para mim foram CTEs — Common Table Expressions.
WITH usuarios_ativos AS (
SELECT usuario_id
FROM sessoes
WHERE criado_em >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY usuario_id
),
pedidos_recentes AS (
SELECT usuario_id, COUNT(*) as total
FROM pedidos
WHERE criado_em >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY usuario_id
)
SELECT u.nome, COALESCE(p.total, 0) as pedidos_ultimo_mes
FROM usuarios u
JOIN usuarios_ativos ua ON u.id = ua.usuario_id
LEFT JOIN pedidos_recentes p ON u.id = p.usuario_id
CTE quebra query complexa em partes com nome. Cada parte é uma transformação intermediária com propósito claro. A query final compõe essas transformações.
Sem CTE, a mesma query seria subquery aninhada dentro de subquery — tecnicamente equivalente, cognitivamente muito mais difícil de ler.
O que GROUP BY ensinou sobre pensar em granularidade:
Granularidade é o nível de detalhe de um resultado. "Um registro por usuário" é granularidade diferente de "um registro por pedido por usuário por dia". SQL força você a ser explícito sobre granularidade — qualquer coluna não agregada no SELECT precisa estar no GROUP BY.
Essa explicitação que parece restrição é, na prática, proteção contra erros de análise. Quando você sabe a granularidade do seu resultado, você sabe o que está contando e o que está somando. Quando não sabe, análise produz números que parecem corretos mas não são.
O que SQL para análise me ensinou sobre código em geral:
Composição de transformações é poderosa. O mesmo dado pode ser transformado de múltiplas formas dependendo da query. SQL é declarativo — você descreve o que quer, não como obter. Isso força separar o "o que" do "como".
Plano de execução importa. A mesma query pode ser escrita de formas diferentes com performance muito diferente. Index, ordem de join, subquery vs. CTE — o banco vai executar, mas executar mal se você escrever de forma ingênua.
Conjunto de dados vs. registro individual. SQL pensa em conjuntos. A maioria das linguagens de programação pensa em iteração sobre registros individuais. Quando você internaliza o pensamento em conjunto, escreve SQL melhor — e também escreve código melhor que processa coleções.
SQL continua sendo uma das habilidades mais versáteis que tenho. Não porque está em todo lugar — mas porque o modelo mental de transformação declarativa de dados aparece em sistemas de análise, em processamento de stream, em queries de banco de dados de todos os tipos.
Aprender SQL para análise, não só para CRUD, foi aprender um modelo mental diferente de processar dado.
Essa semana: você usa SQL só para recuperar dado — ou também para transformar dado antes de chegar ao seu código?