Estruturar um banco de dados relacional parece simples até você precisar de uma consulta que demora 40 segundos. Esses 9 erros são os que mais vi (e cometi) em projetos reais. Os erros mais comuns ao estruturar um banco de dados relacional incluem ignorar a normalização, criar chaves primárias inadequadas, negligenciar índices, misturar tipos de dados na mesma coluna e não definir chaves estrangeiras. Cada um compromete a integridade e a performance do banco.
1. Ignorar a normalização
Guardar tudo em uma tabela gigante parece mais rápido no começo. Mas quando você precisa atualizar o endereço de um cliente que aparece em 200 linhas, descobre o erro. A normalização evita redundância e anomalias de atualização. Um exemplo concreto: separar dados de clientes e pedidos em tabelas distintas, ligadas por chave estrangeira, reduz duplicação e mantém consistência.
2. Criar chaves primárias inadequadas
Usar CPF ou e-mail como chave primária é tentador, mas problemático. CPF pode mudar (sim, acontece), e e-mail também. Prefira chaves surrogatas, como um ID auto-incremento. Elas são imutáveis, mais rápidas em joins e não dependem de regras de negócio que podem mudar.
3. Negligenciar os índices
Sem índices, cada consulta varre a tabela inteira. Um SELECT que deveria levar milissegundos passa a levar segundos. Crie índices para colunas usadas em WHERE, JOIN e ORDER BY. Mas não exagere: cada índice extra desacelera inserções e atualizações. O equilíbrio é a chave.
4. Misturar tipos de dados na mesma coluna
Guardar números e texto na mesma coluna de uma tabela de configuração parece inofensivo. Mas quando você precisa somar ou filtrar, o banco reclama. Separe tipos: colunas de valor numérico para cálculos, colunas de texto para descrições. Isso mantém a integridade referencial e evita conversões forçadas.
5. Não definir chaves estrangeiras
Sem chaves estrangeiras, o banco não impede que você insira um pedido com ID de cliente que não existe. O resultado? Dados órfãos e consultas que retornam NULL sem aviso. Defina FOREIGN KEY desde o início. Elas garantem a integridade referencial e documentam o relacionamento entre tabelas.
6. Usar NULL sem critério
NULL não é um valor, é a ausência dele. Usar NULL em colunas que deveriam ser NOT NULL complica consultas e agregações. Por exemplo, uma coluna de data de nascimento que permite NULL pode indicar que o dado não foi coletado, mas também pode ser um erro. Defina restrições claras: NOT NULL para campos obrigatórios, DEFAULT para valores padrão.
7. Fazer consultas sem planejamento de índices compostos
Um índice em uma única coluna ajuda, mas consultas com múltiplos filtros precisam de índices compostos. Por exemplo, WHERE status = 'ativo' AND data > '2024-01-01' se beneficia de um índice em (status, data). A ordem das colunas no índice importa: coloque as mais seletivas primeiro.
8. Esquecer de documentar o esquema
Sem documentação, ninguém sabe por que aquela tabela tem 15 colunas ou o que significa o campo 'tipo' com valores 1, 2 e 3. Documente o dicionário de dados, as regras de negócio e os relacionamentos. Isso economiza horas de debug quando um novo desenvolvedor (ou você, seis meses depois) precisar entender o modelo.
9. Não testar com volume real de dados
Testar com 100 linhas é enganoso. O banco funciona lindo até você ter 100 mil pedidos. Um JOIN que era rápido explode. Faça testes de carga com dados próximos da realidade. Ferramentas como pgbench ou scripts de inserção em massa ajudam a identificar gargalos antes da produção.
Recomendação prática
Se você está começando, foque em normalizar até a terceira forma normal, use chaves surrogatas e defina chaves estrangeiras. Depois, adicione índices conforme as consultas reais exigirem. Documente tudo. E nunca, jamais, confie em testes com 100 linhas.
FAQ
Qual o erro mais comum ao modelar banco de dados relacional?
Ignorar a normalização. Muita gente cria tabelas com dados repetidos para facilitar consultas iniciais, o que gera redundância e problemas de atualização. A normalização evita isso.
Como saber se meu banco está bem normalizado?
Se você atualiza o mesmo dado em mais de um lugar, provavelmente não está. A terceira forma normal (3FN) é um bom ponto de partida: cada coluna não-chave deve depender apenas da chave primária.
Chave primária pode ser string?
Pode, mas não é recomendado. Strings são mais lentas em comparações e joins, além de ocuparem mais espaço. Prefira inteiros ou UUIDs como chave surrogata.
Quantos índices são demais?
Depende do volume de escrita. Cada índice extra desacelera INSERT, UPDATE e DELETE. Uma regra prática: crie índices apenas para colunas usadas em WHERE, JOIN e ORDER BY, e monitore a performance.
O que fazer com dados órfãos?
Se você já tem dados órfãos (pedidos sem cliente, por exemplo), execute uma consulta para identificá-los e decida: deletar, corrigir ou manter com flag de inconsistência. Depois, adicione a chave estrangeira para evitar novos casos.
Vale a pena desnormalizar para performance?
Em casos específicos, sim, mas com cautela. Desnormalizar acelera leituras, mas complica escritas e pode gerar inconsistências. Faça isso apenas quando monitoramento mostrar que a normalização é o gargalo.