Banco dados relacional: checklist de boas práticas para 2026

Manter um banco de dados relacional saudável não é sobre o SGBD que você escolhe, mas sobre como você estrutura, protege e consulta os dados. Segundo a Wikipedia, um banco de dados relacional é aquele que modela os dados de forma que sejam percebidos pelo usuário como tabelas, ou relações. Essa simplicidade conceitual esconde uma complexidade operacional: sem disciplina, tabelas viram depósitos de dados inconsistentes, consultas ficam lentas e backups falham na hora crítica. Este checklist não é teórico, é o que você verifica antes de dormir, antes de um deploy e antes de entregar um sistema para produção.

1. Modelagem e estrutura de tabelas

1.1 Defina chaves primárias em todas as tabelas

Cada tabela precisa de uma coluna (ou combinação) que identifique unicamente cada linha. Sem chave primária, você não consegue referenciar um registro específico, e o SGBD não consegue garantir integridade. Use INT AUTO_INCREMENT ou UUID, mas nunca deixe uma tabela sem chave.

1.2 Use chaves estrangeiras com consistência

Relacionamentos entre tabelas devem ser explícitos via chave estrangeira. Isso impede órfãos, registros que referenciam algo que não existe. Em sistemas de pedidos, por exemplo, a chave cliente_id na tabela pedidos deve ser uma chave estrangeira para clientes.id.

1.3 Escolha tipos de dados corretos

VARCHAR(255) para tudo é preguiça que custa espaço e desempenho. Use INT para números inteiros, DECIMAL para valores monetários, DATE para datas. Cada tipo errado força conversões implícitas que o SGBD faz em runtime, degradando consultas.

1.4 Evite colunas multivaloradas

Uma coluna que armazena múltiplos valores separados por vírgula viola a primeira forma normal. Exemplo: telefones com "119999-0000, 112222-3333" deveria ser uma tabela separada telefones_cliente. Isso permite consultar, indexar e atualizar cada telefone individualmente.

2. Normalização e desempenho

2.1 Normalize até a terceira forma normal (3FN)

A 3FN elimina dependências transitivas: atributos não-chave não devem depender de outros atributos não-chave. Na prática, se uma tabela pedidos tem cliente_nome e cliente_cidade, esses dados dependem do cliente, não do pedido. Crie uma tabela clientes separada.

2.2 Desnormalize com critério, não por preguiça

Desnormalização é aceitável para relatórios ou leitura intensa, mas documente o motivo. Exemplo real: uma tabela de logs pode armazenar o nome do usuário junto com o log para evitar JOIN em cada consulta de auditoria. O custo é redundância controlada.

2.3 Evite colunas calculadas no banco

preco_total que é quantidade * preco_unitario deve ser calculado na aplicação ou via GENERATED COLUMN, nunca armazenado manualmente. Dados derivados tendem a dessincronizar com os originais.

3. Índices e consultas

3.1 Crie índices para colunas usadas em WHERE e JOIN

Índices aceleram buscas, mas cada índice extra diminui a velocidade de INSERT/UPDATE. Um contraexemplo comum: indexar colunas booleanas (sexo, ativo) não ajuda porque a seletividade é baixa, o SGBD vai ler metade da tabela de qualquer forma.

3.2 Use índices compostos na ordem correta

Se você filtra por (cidade, data_cadastro), o índice deve seguir essa ordem. Colocar a coluna mais seletiva primeiro reduz o espaço de busca mais rapidamente.

3.3 Monitore consultas lentas com EXPLAIN

Antes de otimizar no escuro, execute EXPLAIN na consulta suspeita. Ele mostra se o SGBD está usando índice, fazendo full scan ou usando tabela temporária. Um full scan em tabela de 10 milhões de linhas nunca é aceitável em produção.

4. Integridade e consistência

4.1 Use transações com BEGIN/COMMIT/ROLLBACK

Operações que afetam múltiplas tabelas (transferência bancária, por exemplo) devem estar dentro de uma transação. Se uma etapa falha, o ROLLBACK desfaz tudo. Sem transação, você pode ter um débito sem o crédito correspondente.

4.2 Defina constraints de CHECK

Restrições como CHECK (idade >= 0) ou CHECK (status IN ('ativo', 'inativo')) impedem dados inválidos na origem. A aplicação pode falhar, mas o banco não aceita o absurdo.

4.3 Faça backup testado semanalmente

Backup que não é restaurado não é backup. Teste a restauração em ambiente separado ao menos uma vez por semana. Um erro comum: confiar que o dump noturno funciona sem nunca verificar o arquivo.

5. Segurança e acesso

5.1 Crie usuários com privilégios mínimos

A aplicação não precisa de DROP TABLE ou ALTER. Crie um usuário específico para leitura e outro para escrita, com permissões apenas nas tabelas necessárias. Nunca use root na string de conexão.

5.2 Criptografe dados sensíveis em repouso

Senhas, CPF e dados bancários devem ser armazenados com hash (bcrypt, argon2) ou criptografia AES. Se o banco for comprometido, o dado cifrado ainda protege o titular.

5.3 Ative logs de auditoria para alterações críticas

Saiba quem alterou o que e quando. Em bancos relacionais, o log de transações ou triggers de auditoria registram mudanças em tabelas sensíveis como usuarios e financeiro.

O erro mais comum que compromete bancos relacionais

O erro não é escolher a ferramenta errada, é tratar o banco como um depósito e não como um sistema de relações. Profissionais que pulam a modelagem e vão direto para as queries acabam com tabelas sem chave, dados duplicados e consultas que demoram minutos. Um banco relacional só é confiável quando cada tabela, cada chave e cada índice tem uma razão de existir. Se você não sabe por que uma coluna está ali, ela provavelmente não deveria estar.

FAQ sobre banco de dados relacional

O que é um banco de dados relacional?

É um banco que organiza dados em tabelas (relações) interligadas por chaves, garantindo integridade referencial e consultas via SQL. Cada tabela representa uma entidade e cada linha, uma ocorrência dessa entidade.

Qual a diferença entre banco relacional e não relacional?

Bancos relacionais usam esquema fixo, tabelas e SQL. Bancos não relacionais (NoSQL) aceitam dados semiestruturados, escalam horizontalmente com mais facilidade e sacrificam consistência imediata por disponibilidade.

Quando desnormalizar um banco relacional?

Quando a leitura é muito mais frequente que a escrita e o custo do JOIN é inaceitável para a performance esperada. Exemplo: tabelas de relatório ou dashboards em tempo real.

O que é integridade referencial?

É a garantia de que um valor em uma chave estrangeira sempre corresponde a uma chave primária existente. Impede que um pedido referencie um cliente que foi deletado.

Qual a diferença entre chave primária e chave estrangeira?

Chave primária identifica unicamente uma linha dentro da própria tabela. Chave estrangeira referencia a chave primária de outra tabela, estabelecendo o relacionamento entre elas.

Preciso normalizar até a 3FN sempre?

Sim, como ponto de partida. A 3FN elimina a maioria das anomalias de atualização. Depois, avalie se a desnormalização pontual é justificada por performance, e documente cada exceção.