Por que as restrições são aplicadas no banco de dados? Não será mais flexível colocá-lo no código?
Estou lendo um livro para iniciantes sobre como implementar bancos de dados, então estou perguntando isso como iniciante. Digamos que eu tenha projetado um banco de dados, incluindo este modelo de entidade:
entity type | sub-types
----------------+--------------------------------------------
Person | Employee, Student, ...
Student | Graduate, Undergraduate, ...
Employee | Teacher, Administrator, ...
Restrições atuais:
- A pessoa cadastrada no sistema só pode ser Aluno ou Funcionário.
- A entidade de pessoa requer a exclusividade do número social, que presumimos que cada pessoa possui apenas um único número (também conhecido como uma chave primária boa o suficiente ). (veja #1)
Depois resolvemos tirar o número 1: Se um dia a faculdade decidir que o Teacher(o Employeesubtipo) também pode ser Student, fazendo cursos nas horas vagas, fica muito mais difícil mudar o desenho do banco de dados que pode ter milhares, milhões, bilhões, zilhões de entradas em vez de apenas mudar a lógica do código: apenas a parte que não permitia que uma pessoa fosse cadastrada como aluno e funcionário.
(É muito improvável, mas não consigo pensar em mais nada agora.Aparentemente é possível).
Por que nos preocupamos com as regras de negócios no design do banco de dados e não no código?
# 1: Uma nota 7 anos depois, um exemplo da vida real:
eu vi um governo onde, por engano, os SSNs emitidos foram duplicados: várias pessoas, mesmo SSN. Aqueles que projetaram o banco de dados original definitivamente cometeram o erro de não aplicar essa restrição de exclusividade no banco de dados. (e mais tarde um bug no aplicativo original? vários aplicativos usando o banco de dados compartilhado e não concordando onde colocar, verificar e aplicar a restrição? ...).
Esse bug continuará a residir no sistema e em todo o sistema desenvolvido, após o qual dependerá do banco de dados do sistema original por muitos e muitos anos. Lendo as respostas aqui, aprendi a aplicar todas as restrições, o máximo possível, sabiamente (não cegamente) no banco de dados para representar o mundo físico real da melhor maneira possível.