Que Funcionalidade Dos Sistemas De Banco De Dados Permite Prevenir

Entendendo as constraints: o que realmente impede seus dados de virarem bagunça

Muita gente acha que banco de dados é só guardar informação e recuperar quando precisa. A parte que separa quem tem tabelas que funcionam de quem passa o mês inteiro apagando registros incorretos são as constraints. Essa é a funcionalidade dos sistemas de banco de dados permite prevenir inconsistências, violações e comportamentos inesperados nos seus dados. Constraints são regras que o SGBD aplica automaticamente antes de deixar um dado entrar ou depois de removê-lo. Você define a regra uma vez, e o banco se encarrega de respeitar ela a cada INSERT, UPDATE ou DELETE. Sem elas, depende da aplicação validar tudo manualmente, o que raramente funciona na prática porque alguém sempre esquece de chamar a verificação. No dia a dia, eu já vi equipe inteira perder dois dias refazendo importações porque ninguém colocou UNIQUE em um campo que claramente deveria ser único. O banco tinha aceitado os registros, a aplicação não estava checando, e no final tinham duas contas para o mesmo CPF, três endereços duplicados e um relatório financeiro completamente errado. Depois de colocar a constraint correta, o problema sumiu. Simples assim.

As constraints mais usadas são PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK e DEFAULT. Cada uma resolve um tipo específico de problema. Primary key define a identidade única da linha. Foreign key liga tabelas e evita registros órfãos. Unique protege contra repetição indesejada. Not null garante que campos obrigatórios realmente tenham valor. Check aplica lógica arbitrária, como um salário positivo. Default preenche valores quando nada é informado.

Por que confiar só na aplicação não funciona

Desenvolvedores costumam colocar validação no código porque é mais visível e fácil de debuggar. Funciona até o momento em que dois processos atualizam a mesma tabela ao mesmo tempo, ou um script interno esquece de verificar o campo, ou alguém injeta dados direto pelo SQL. Aí a validação da aplicação simplesmente não existe mais. Constraints no banco resolvem esse problema porque são aplicadas no nível mais baixo possível. Não importa se a requisição vem da API, de um batch noturno, de uma migração manual ou de um colega testando no terminal. O banco vai rejeitar o registro ilegal e retornar erro. Você pode tratar esse erro na aplicação ou apenas logar, mas os dados ruins não entram.

Edge case que quase me custou um deploy

Num projeto de e-commerce, tínhamos uma constraint FOREIGN KEY entre pedidos e estoque. Tudo parecia funcionar, mas em produção acontecia de um pedido ser criado, o estoque ser reduzido, e o pedido ser cancelado segundos depois. O estorno do estoque não acontecia porque a trigger de rollback estava mal configurada e falhava silenciosamente em alguns casos. A solução não foi confiar mais na trigger. Foi adicionar uma constraint CHECK na tabela de movimentações que garantia que o saldo nunca ficaria negativo, e criar um job diário que comparava o estoque teórico com o físico e corrigia divergências. Constraints sozinhas não resolvem lógica de negócio complexa, mas pelo menos impedem que o sistema entre em estado impossível sem você saber.

Quando constraints não são a resposta certa

Tem situação em que poner constraint trava mais do que ajuda. Regras de negócio que mudam frequentemente, dados históricos que precisam sobreviver a mudanças de política, ou tabelas com milhões de linhas onde every insert vira um gargalo por causa de verificações extras. Nesses casos, constraint pode gerar lentidão ou até bloqueios desnecessários. Também existe o problema das constraints desabilitadas. Alguns bancos permitem dropar ou disable por motivos de manutenção ou migração. Se você fizer isso e esquecer de reativar, volta pro ponto zero. Sempre deixe documentação do porquê uma constraint foi removida e crie alertas para mudanças no schema.

Dicas práticas que realmente importam

Nomeie suas constraints de forma clara. ERRO_DEVELOPER_01 não ajuda ninguém. ON DELETE CASCADE deve ser usado com cautela porque exclui dados sem aviso. ON DELETE SET NULL é mais seguro em muitos cenários. Teste constraints em ambiente de staging antes de aplicar em produção, especialmente em tabelas grandes, porque o banco pode precisar reescrever registros existentes. Use CHECK para regras simples. Se a lógica precisar de consulta em outra tabela, considere trigger ou validação na aplicação, porque CHECK não acessa outras tabelas diretamente. Primary keys devem ser imutáveis. Se precisar mudar o identificador depois, provavelmente escolheu a estratégia errada.

Conclusão

Constraints são a linha de defesa mais barata e eficiente que você tem contra dados corrompidos. Elas não substituem bom design de aplicação, mas completam o que o código não consegue garantir. Aprender a usá-las corretamente economiza horas de limpeza manual e evita problemas que só aparecem meses depois da instalação.