Frameworks vêm e vão, linguagens sobem e descem no ranking, times inteiros se renovam. Sabe o que sobrevive a tudo isso? O modelo de dados. A tabela desenhada às pressas em 2019 continuará cobrando pedágio de cada feature em 2029. É a decisão de maior meia-vida da engenharia, e a que menos recebe atenção proporcional.

Depois de percorrer PostgreSQL vs MongoDB, Redis e DynamoDB, este artigo fecha a série com o que vale para todos eles: os princípios de modelar bem.

Princípio 1: o modelo segue o acesso, não o formulário

O erro de origem da maioria dos modelos ruins: copiar a estrutura da tela ou do documento de requisitos. A pergunta certa é operacional: como esses dados serão lidos e escritos, com que frequência, por quem?

• Leitura 1000x mais frequente que escrita? Desnormalizar um campo calculado pode valer ouro.
• Escrita intensa e concorrente? Cuidado com o contador único que todo mundo atualiza (o hotspot clássico).
• Consulta sempre pelo agregado inteiro? Talvez seja um documento. Sempre por chave? Talvez seja o Dynamo.

Modelar sem conhecer o padrão de acesso é decorar a casa antes de saber quem vai morar nela.

Princípio 2: normalize por padrão, desnormalize por medição

A normalização (cada fato num lugar só) não é purismo acadêmico: é a garantia de que não existem duas versões da verdade. O endereço duplicado em três tabelas vai divergir; é questão de tempo.

A desnormalização tem seu lugar, como otimização deliberada e documentada: o total_do_pedido gravado (em vez de somado a cada leitura), o nome do produto congelado no item do pedido (snapshot histórico, que aliás é requisito de negócio, não otimização). A regra: desnormalizou, defina quem atualiza e quando, ou você criou um bug agendado.

Princípio 3: índice é a arte de pagar na escrita para ganhar na leitura

A query lenta de produção quase nunca é culpa do banco; é a ausência (ou o excesso) do índice certo:

-- A query que o suporte reclama:
SELECT * FROM pedidos WHERE cliente_id = 42 AND status = 'pendente'
ORDER BY criado_em DESC LIMIT 20;

-- O índice que a serve inteira (filtro + ordenação):
CREATE INDEX idx_pedidos_cliente_status
ON pedidos (cliente_id, status, criado_em DESC);

As três regras de bolso: componha o índice na ordem da query (igualdade primeiro, intervalo/ordenação depois); todo índice custa em cada INSERT/UPDATE, então índice que nenhuma query usa é peso morto; e EXPLAIN ANALYZE é o juiz, não a intuição. Meça antes de otimizar, aqui também.

Princípio 4: o modelo vai mudar, então planeje a mudança

O esquema perfeito e imutável não existe; o que existe é migração bem-feita:

• Migrações versionadas no repositório, aplicadas pela esteira, nunca SQL na mão em produção.
• Mudanças em duas fases (expand/contract): adicione a coluna nova, escreva nas duas, migre os leitores, remova a antiga. Zero downtime, rollback possível em cada etapa.
• Ensaiadas em cópia da produção: a migração que trava a tabela por 40 minutos se descobre no ensaio, não na sexta à noite.

Princípio 5: nomes são documentação permanente

tbl_aux2, flag3, data1: cada nome críptico é uma pergunta que alguém fará para sempre. Convenções simples (singular ou plural, mas um só; criado_em e não três variações; nada de abreviação criativa) custam zero e pagam em cada onboarding. O modelo de dados é lido por décadas; escreva para o leitor de 2030.

O teste de qualidade de um modelo

Três perguntas que aplicamos em auditoria:

1. As perguntas frequentes do negócio viram queries simples? Se todo relatório exige seis joins acrobáticos e uma CTE de 80 linhas, o modelo não reflete o domínio.
2. Existe uma verdade só para cada fato? (Ou há três lugares dizendo o estoque, cada um com um número?)
3. Dá para mudar sem medo? Migrações versionadas, ambiente de ensaio, duas fases. Se mudar o esquema é evento traumático, o problema não é o esquema; é o processo.

Modelagem e a estratégia de evolução dela são o coração do nosso serviço de Arquitetura de Software: é a fundação de que tudo o mais depende.

Qual é a query mais lenta ou o relatório mais doloroso do seu sistema? Descreva para a IA da Rabelo Digital, aqui no canto da tela, e ela aponta o provável pecado de modelagem por trás. Sem formulário, sem espera.

---

Leia também

• PostgreSQL vs MongoDB: como escolher
• Redis: muito além do cache
• DynamoDB: escala infinita com regras rígidas