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

Question

外键，约束，默认值等项目是否应由数据库管理系统（在本例中为MS Sql 2005）或应用程序处理？我听过双方的意见，老实说我不知道​​该走哪条路。

我原本打算将它构建到数据库中，但是我发现使用当前的数据库设计并不总是这样。例如，某些表包含循环引用，无法使用ON UPDATE CASCADE进行链接。我遇到的另一个问题是我们可能会使用多个数据库/服务器，并且外键约束在链接服务器上不起作用。

我让一些开发人员建议我在应用程序层进行数据验证，并将数据库保留为存储数据的地方。我喜欢这个想法，但我已经在很多地方读过，最好在数据库中建立参照完整性，以允许不通过应用层传递的事务。我同意这一点，虽然当我们完成所有数据库事务时应该通过应用程序。即使我们决定稍后构建插件，我们也在使用ObjectModel框架，因此永远不需要重写插入/更新/删除查询。

所以我的问题是，在这种情况下，您是否仍然建议将引用完整性构建到数据库中，还是可以将其构建到应用程序层中？为什么？

Answer 1

您应该在数据库中尽可能多地进行数据完整性维护。一旦声明它就会“免费”，并且无论数据如何到达数据库，都可以保证应用。对我来说，这似乎是不费脑子的。

您提出了几个无法在数据库中以声明方式指定的数据库完整性类型的实例。在这些情况下，显然，您必须将完整性编程到中间层或前端，并希望最好。

Answer 2

使用数据库获取最佳效果。包含参照完整性 - 它内置于数据库中，可确保您的数据处于一致状态。

如果这不适合您应用程序中的特定内容，请在应用程序逻辑/域模型中构建它。

就个人而言，如果可能的话，我会确保为应用程序和数据库添加引用逻辑（深度防御）。

Answer 3

数据库管理系统何时可以，应用程序何时不能。您希望在最远的技术上实施强制执行，因此构建在其上的任何东西都可以利用它。