Meu RDBMS com vários servidores ou meu Aplicativo devem lidar com a Integridade Referencial do banco de dados?

Itens como chaves estrangeiras, restrições, valores padrão etc. devem ser manipulados pelo sistema de gerenciamento de banco de dados (neste caso, MS SQL 2005) ou pelo aplicativo? Ouvi opiniões de ambos os lados e sinceramente não tenho certeza de qual caminho seguir.

Há uma chance de estarmos abrangendo vários servidores / bancos de dados e não acho que Chaves Estrangeiras possam ser usadas em servidores vinculados. Além disso, existem algumas referências circulares no design do banco de dados que me impedem de usar ON UPDATE CASCADEem tudo.

O banco de dados é o MS SQL 2005 (possivelmente 2008) e todas as interações com ele devem passar pelo aplicativo.

Se houver alguma chance de o banco de dados ser modificado fora do seu aplicativo, você deseja as restrições no banco de dados. Se o banco de dados é e sempre será nada além do back-end do aplicativo, você pode excluí-los, embora eu os documentasse apenas por precaução e provavelmente apenas os manteria se o desempenho não fosse tão ruim. (O software Peoplesoft funciona dessa maneira - as restrições estão no software e (não estou inventando isso) ele executa tudo como SYS no Oracle.)

Você deseja que coisas assim sejam monitoradas pelo aplicativo, para que ele possa reagir de maneira inteligente e não, na melhor das hipóteses, exibir uma mensagem de erro do banco de dados ao usuário.

E, sim, é uma cobertura dupla, mas sem ela você provavelmente terá corrupção de dados evitável ou uma interface de usuário ruim.

Idealmente, ambos. Você não deve não ter o DB lidar com isso, mas, novamente, se o aplicativo vem com dados que o DB irá rejeitar, isso é um erro de execução, de modo que o aplicativo deve ter pelo menos algum código dedicado a preservar a integridade referencial. Além disso, configurar as restrições corretas no SQL no banco de dados é muito mais simples do que configurar o código para o lado do cliente, portanto, fazê-lo no banco de dados reduz bastante a quantidade de trabalho que você precisa fazer.

Se for importante, deixe o banco de dados lidar com isso. Dessa forma, você não precisa se preocupar com alguém acessando o banco de dados fora do aplicativo e alterando ou inserindo alguns dados inconsistentes ou duplicados. A menos que seja algo específico de aplicativo de alto nível (como "apenas usuários do departamento X com uma classe de acesso ZZZ devem pertencer ao grupo 999"), mas isso geralmente não é chamado de integridade "referencial".

Eu diria que colocar no banco de dados. Se você estiver usando uma estrutura persistente, ela pegará as chaves automaticamente.

Ambos são definitivamente o caminho a percorrer. Você deseja uma lógica de validação no seu código para evitar atualizações e inserções incorretas, além de informar aos usuários o que estava errado e como corrigi-lo. E ter o banco de dados lá para interromper as coisas, portanto, se algo chegasse e não fosse executado na validação, isso não quebraria as coisas na linha é uma coisa boa.

Você deve manter o material do banco de dados em nível superior. Por exemplo, imponha integridade referencial e talvez algumas não sejam nulas. Mas não se preocupe em restringir comprimentos ou formatos, pois isso é melhor para o aplicativo.