# Banco dados relacional: checklist de boas práticas para 2026 > Banco de dados relacional exige modelagem cuidadosa com normalização até a terceira forma normal para evitar redundâncias. Índices bem planejados aceleram consultas, enquanto segurança inclui criptografia e controle de acesso. Manutenção periódica com backups e monitoramento de desempenho previne gargalos. O checklist de 2026 orienta equipes técnicas a aplicar essas práticas para garantir eficiência e confiabilidade. *Net Propaganda · Apps e Software · 23 de julho de 2026 · Walquíria Bensaúde Tomaz* Um banco de dados relacional organiza dados em tabelas com relacionamentos definidos, mas sem boas práticas ele vira um gargalo. Este checklist cobre modelagem, normalização, índices, segurança e manutenção para equipes técnicas. 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. --- Fonte (canonical): https://netpropaganda.com.br/apps-e-software/banco-dados-relacional-checklist-de-boas-praticas-para-2026/