我的多服务器RDBMS或我的应用程序应该处理数据库参照完整性吗？

是否应由数据库管理系统（在这种情况下为MS SQL 2005）或应用程序处理外键，约束，默认值等项？我听取了双方的意见，老实说，我不确定该走哪条路。

我们有机会跨越多个服务器/数据库，而且我认为外键不能在链接的服务器之间使用。除此之外，数据库设计中还有一些循环引用，这使我无法ON UPDATE CASCADE在所有内容上使用。

该数据库是MS SQL 2005（可能是2008），与数据库的所有交互都应通过应用程序进行。

如果有可能在应用程序外部修改数据库，则需要数据库中的约束。如果数据库始终是应用程序的后端，那么您可以不理会它们，尽管我已经为它们做了文档记录，以防万一，如果性能影响还不错的话，可以保留它们。（Peoplesoft软件以这种方式工作-约束存在于软件中，并且（我没有做这件事）它在Oracle上以SYS身份运行所有内容。）

您希望由应用程序监视类似的事情，因此它可以做出明智的反应，并且最多不会向用户派发数据库错误消息。

而且，是的，这是双重覆盖，但如果没有它，您可能会得到可预防的数据损坏或错误的用户界面。

理想情况下，两者。你不应该不具备DB处理它，但话又说回来，如果应用程序自带了数据，该数据库将拒绝，这是一个运行时错误，因此应用程序至少应该有一些代码致力于维护参照完整性。而且，在数据库中用SQL设置正确的约束比在客户端为其设置代码要简单得多，因此在数据库上进行设置大大减少了您需要做的工作量。

如果很重要，请数据库处理。这样，您就不必担心有人在应用程序外部访问数据库并更改或输入一些不一致或重复的数据。除非是一些高级的特定于应用程序的内容（例如“仅允许X部门中具有ZZZ访问级别的用户属于组999”），否则通常不将其称为“参照”完整性。

我会说放在数据库中。如果您使用的是持久性框架，它将自动获取密钥。

两者都是必经之路。您将需要代码中的验证逻辑来​​防止错误的更新和插入，并告诉用户出了什么问题以及如何解决。并且拥有数据库来支持事情，因此，如果有事情出现并且没有通过验证，那么事情就不会中断了，这是一件好事。

您应该将数据库内容保持较高级别。EG，强制执行引用完整性，也许有些不为null。但是不必担心会限制长度或格式，因为最好将其完全呈现给应用程序。