Banco de dados: a modelagem que sustenta (ou derruba) o produto
O banco de dados costuma ser a parte mais permanente de um sistema. Interfaces mudam, linguagens são substituídas, serviços são reescritos — os dados, e a forma como foram modelados, ficam. Por isso, decisões de modelagem merecem o tipo de cuidado que normalmente é reservado à arquitetura geral.
Modelar é descrever regras do negócio, não desenhar telas
Um bom modelo expressa o que existe no domínio e quais relações são obrigatórias. Quando a modelagem parte da tela, o resultado é um conjunto de tabelas que reflete a interface do primeiro mês e resiste mal à segunda funcionalidade.
Chaves, restrições de unicidade e integridade referencial não são burocracia: são regras de negócio escritas no lugar onde nenhuma parte da aplicação consegue burlar por engano.
- Restrições no banco garantem invariantes mesmo com múltiplos serviços escrevendo.
- Normalizar primeiro; desnormalizar depois, com medição e motivo explícito.
- Campos de estado devem ter domínio fechado, não texto livre.
Índices resolvem leitura e cobram na escrita
Índice é uma troca: acelera consultas específicas e adiciona custo a cada gravação. A escolha deve nascer das consultas reais do produto, observadas em produção, e não de suposições feitas antes do primeiro usuário.
Analisar o plano de execução de uma consulta lenta costuma revelar mais em dez minutos do que uma semana de otimização por intuição.
SQL, NoSQL e a pergunta certa
A pergunta útil não é qual tecnologia é melhor, e sim que garantias o domínio exige. Onde há dinheiro, estoque, contrato ou qualquer invariante que não pode quebrar, transações e consistência forte valem mais do que flexibilidade de esquema.
Bancos relacionais modernos absorvem documentos, buscas e séries temporais com competência. Introduzir uma segunda tecnologia deve ser resposta a um limite medido, não a uma preferência estética.
Migrações e evolução sem parar o produto
Esquema muda. O que separa uma equipe tranquila de uma equipe em pânico é o processo: migrações versionadas, aplicadas em etapas compatíveis com a versão anterior do código, sempre reversíveis e testadas antes de tocar produção.
Em resumo
Modelo de dados é decisão de longo prazo: escreva as regras do domínio no banco, meça antes de otimizar e trate migração como parte normal do ciclo de entrega.
Casos de uso
SaaS multiempresa
Isolamento por organização com chave em todas as tabelas e políticas de acesso aplicadas no próprio banco.
Relatórios pesados
Separação entre carga transacional e analítica, com visões materializadas atualizadas em janela controlada.
Fila de trabalho
Estados explícitos, bloqueio por linha e idempotência para evitar processamento duplicado.
Erros comuns
- Guardar valores monetários em ponto flutuante.
- Usar texto livre para status e depois depender de comparação de strings.
- Criar índice para toda coluna, degradando escrita sem ganho real de leitura.
- Fazer migração destrutiva sem plano de reversão.
Boas práticas
- Tipos corretos desde o início, incluindo fuso horário em datas.
- Restrições de integridade no banco, não apenas na aplicação.
- Consultas observadas com métrica de tempo e frequência.
- Backup testado por restauração real, em intervalo definido.
Livros recomendados
Designing Data-Intensive Applications — Martin Kleppmann
Explica trade-offs de consistência, replicação e particionamento com rigor e clareza.
SQL Performance Explained — Markus Winand
Torna concreto o efeito de índices e planos de execução no desempenho.
Database Design for Mere Mortals — Michael J. Hernandez
Base sólida de modelagem para quem está começando.
Para aprofundar
Perguntas frequentes
- Devo escolher SQL ou NoSQL?
- Comece pelas garantias que o domínio exige. Se há invariantes críticas e relações ricas, o relacional costuma ser a escolha mais segura.
- Quando criar um índice?
- Quando uma consulta frequente e lenta é comprovada por medição, e o ganho de leitura compensa o custo de escrita.
- Normalizar sempre?
- Normalize por padrão. Desnormalize pontualmente, com dado medido e com controle explícito de atualização.
- Como evitar perda de dados em migração?
- Migração em etapas compatíveis, execução ensaiada em cópia de produção, reversão pronta e backup verificado antes.
Referências
- Martin Kleppmann — garantias de consistência em sistemas distribuídos
- Markus Winand — uso de índices e leitura de planos de execução
- Documentação do PostgreSQL — transações e isolamento
Conteúdo original da equipe i9 Conecty. Conceitos clássicos são explicados com palavras próprias e creditados aos seus autores.