Normalização vs pragmatismo: quando cada um

O problema

Toda conversa sobre modelagem de dados tende a escorregar para um dos dois extremos.

Extremo 1:

• “precisa normalizar tudo direito”

Extremo 2:

• “na prática ninguém faz isso, vamos deixar simples”

Os dois podem errar feio.

Normalizar demais pode deixar leitura mais difícil, aumentar join desnecessário e complicar o fluxo sem ganho real.

Desnormalizar demais pode espalhar regra, duplicar dado crítico e criar inconsistência difícil de rastrear.

Então o problema não é escolher um lado da briga.

É saber quando separar ajuda de verdade e quando a aproximação é uma escolha pragmática e controlada.

Modelo mental

Pense assim:

normalizar é aproximar o schema da fonte única da verdade; pragmatizar é aceitar custo local para simplificar o sistema real.

Essa frase ajuda porque normalização e pragmatismo não são opostos morais.

São ferramentas.

Normalização costuma ajudar quando você quer:

• reduzir duplicação
• evitar inconsistência
• deixar regra explícita
• manter atualização confiável

Pragmatismo costuma aparecer quando você quer:

• simplificar leitura muito frequente
• guardar snapshot histórico
• reduzir custo operacional de uma query crítica
• refletir melhor o jeito como o produto realmente usa o dado

Ou seja:

normalizar não é ser mais sério.

Desnormalizar não é ser mais prático por definição.

Tudo depende do problema real.

Quebrando o problema

Normalização resolve um tipo específico de dor

Vale lembrar o benefício central.

Quando você separa melhor o dado, você reduz situações como:

• mesmo cliente salvo em cinco lugares com nomes divergentes
• mesma regra de negócio aplicada de jeitos diferentes
• atualização de um campo exigindo vários writes manuais

Esse ganho importa bastante quando:

• o dado muda com frequência
• a consistência importa
• a regra precisa de fonte única clara

Se o preço atual de um produto muda e todo o sistema depende desse valor correto, duplicar isso sem controle costuma ser uma péssima ideia.

Pragmatismo aparece quando o sistema real cobra outra coisa

Agora o outro lado.

Tem caso em que a separação perfeita no diagrama piora a vida no produto.

Exemplos:

• tela quase sempre precisa juntar as mesmas cinco tabelas
• você precisa guardar snapshot de algo no momento da transação
• uma leitura crítica ficaria cara demais sem aproximação

Nesses cenários, às vezes faz sentido aceitar:

• dado duplicado
• campo derivado persistido
• estrutura mais próxima da leitura

Mas com uma condição:

essa duplicação precisa ter dono e regra de atualização.

Se não tiver, não é pragmatismo.

É só bagunça adiada.

Snapshot não é o mesmo que dado redundante sem critério

Essa confusão aparece o tempo todo.

Imagine um pedido.

Você pode ter:

• customer_id apontando para o cliente atual
• nome e endereço capturados no momento da compra

Alguém pode olhar isso e dizer:

• “mas o nome já existe em customer, isso está duplicado”

Nem sempre essa crítica faz sentido.

Se o pedido precisa preservar o estado daquele momento, isso não é duplicação boba.

É snapshot.

Snapshot histórico é um caso clássico em que pragmatismo faz sentido.

Porque a verdade que você quer guardar não é “quem o cliente é hoje”.

É “o que valia no momento daquela compra”.

Join caro nem sempre é o problema real

Também vale evitar um reflexo simplista:

• “tem muito join, então vamos desnormalizar”

Às vezes o problema nem é a modelagem.

Pode ser:

• query ruim
• índice ausente
• filtro mal feito
• ORM montando consulta péssima

Se você desnormaliza cedo demais, pode esconder o gargalo errado e ainda comprar inconsistência.

Então a ordem saudável costuma ser:

1. entender a leitura real
2. medir o gargalo
3. só depois decidir se a modelagem precisa mudar

Duplicação sem estratégia cobra juros

Sempre que você duplica dado importante, precisa responder:

• quem atualiza as cópias?
• em que momento?
• o que acontece se uma falhar?
• qual versão o produto considera verdade?

Se essas respostas não existem, a duplicação vira fábrica de bug.

Isso aparece muito em campos como:

• status
• preço
• saldo
• permissão

São exemplos de dado que parecem fáceis de copiar até o dia em que divergem.

Nem toda simplicidade vem da menor quantidade de tabelas

Esse ponto é importante.

Às vezes a estrutura mais simples para o sistema não é a que tem menos tabela.

É a que deixa:

• regra visível
• escrita previsível
• leitura compreensível
• evolução menos traumática

Tem esquema com pouca tabela e muita confusão.

E tem esquema um pouco mais separado que fica muito mais claro para manter.

Exemplo simples

Imagine um sistema de assinatura.

Você tem:

• users
• plans
• subscriptions
• invoices

Uma abordagem purista poderia tentar sempre ler nome do plano, preço e ciclo diretamente da tabela atual de plans.

O problema:

• o plano pode mudar
• o preço atual pode mudar
• a fatura antiga precisa refletir o valor cobrado naquela época

Então faz sentido que invoices guarde snapshot de:

• nome do plano
• valor cobrado
• moeda

Isso é pragmatismo bom.

Agora imagine que, além disso, o time decide copiar também:

• email do usuário
• status da assinatura
• limite do plano
• data de renovação

em metade das tabelas, sem regra clara de atualização.

Aí o sistema vira uma loteria:

• cada tela lê uma versão
• cada job atualiza um pedaço
• ninguém sabe qual valor é o certo

Essa é a diferença prática.

Uma duplicação ajuda a preservar contexto.

A outra espalha verdade demais pelo sistema.

Erros comuns

Tratar normalização como troféu técnico

Se a resposta é “porque o banco fica mais bonito”, está fraca.

Chamar bagunça de pragmatismo

Duplicar dado sem dono e sem estratégia de sincronização não é pragmatismo.

Desnormalizar antes de medir

Sem entender leitura, escrita e gargalo, a mudança vira chute caro.

Ignorar histórico

Alguns dados precisam refletir o estado atual.

Outros precisam preservar o estado passado.

Misturar essas duas necessidades cria confusão rápida.

Esquecer o custo de evolução

A estrutura que parece mais rápida hoje pode ser a que mais dói quando a regra muda.

Como um senior pensa

Um senior normalmente evita responder esse tema com frase pronta.

Ele tende a perguntar:

• esse dado muda com frequência?
• ele precisa de fonte única?
• eu preciso do estado atual ou de snapshot histórico?
• essa leitura é tão crítica que justifica aproximação?
• como vou manter consistência entre cópias?

Repare na diferença.

Não é:

• “normalização é melhor”

Nem:

• “na prática todo mundo desnormaliza”

É:

• “qual problema real essa decisão resolve e qual problema novo ela cria?”

Esse tipo de raciocínio passa muito melhor em projeto e em entrevista.

O que o entrevistador quer ver

Quando esse assunto aparece, o entrevistador geralmente quer descobrir se você sabe fazer trade-off de verdade.

Ele quer ver se você:

• entende por que normalização existe
• sabe quando snapshot ou duplicação controlada faz sentido
• conecta modelagem a leitura, escrita e histórico
• não usa pragmatismo como desculpa para desorganização

Uma resposta forte costuma soar assim:

1. normalização reduz inconsistência e deixa regra clara
2. pragmatismo faz sentido quando existe leitura crítica, snapshot histórico ou custo real de acesso
3. qualquer duplicação precisa de dono e regra explícita

Se você mostrar isso com um exemplo concreto, já sai muito na frente.

Normalizar e desnormalizar são decisões de engenharia, não posições ideológicas.

O dado pode até morar em mais de um lugar, mas a verdade do sistema não deveria ficar sem dono.