是否应该执行参照完整性？

Question

不应强制执行引用完整性的原因之一是性能.因为Db必须根据关系验证所有更新,它只会使事情变慢,但执行和不执行的其他优缺点是什么？

因为无论如何都要在业务逻辑层中维护关系,所以它只会让db成为冗余.你对此有什么想法？

Answer 1

数据库负责数据.而已.期.

如果没有在数据库中完成引用完整性,那么它就不是完整性.它只是相信人们不会做坏事,在这种情况下你甚至可能不担心密码保护你的数据:-)

谁能说你不会让某人编写自己的JDBC连接客户端来完全搞砸数据,尽管你精心设计并且没有错误的业务层(事实上它可能不会没有 bug ,这完全是另一个问题) ,强制数据库应该保护自己).

Answer 2

首先,几乎不可能让它真正正常工作.为了有正确的工作机会,你需要将许多级联修改包装为事务,这样你在更改数据库的一部分时就不会有不同步的东西,但仍在更新依赖于其他部分的数据库.首先.这意味着代码应该简单并且只知道业务逻辑突然需要知道所有类型的并发问题.

其次,保持工作几乎是不可能的 - 每当有人触及业务逻辑时,他们需要再次处理这些并发问题.

第三,这使得参照完整性难以理解 - 将来,当有人想要了解您的数据库结构时,他们将不得不从业务逻辑中对其进行逆向工程.有了它在数据库中,它是独立的,所以你要看的只涉及参照完整性,而不是各种不相关的问题.您有(例如)直接逻辑链,显示对特定字段的修改将触发的内容.至少对于相当多的数据库,该逻辑可以被自动提取并变成相当有用的文档(例如,显示依赖性的树图).从BLL中提取相同类型的信息更可能是一个相当严肃的项目.

在另一个方向肯定有一些要点,并且有理由通过手工制作所有这些 - 可扩展性和性能最明显.但是,如果你走这条路,你应该知道你放弃了什么以获得这种表现.在某些情况下,这是值得的权衡 - 但在其他情况下它不是,并且您需要信息来做出合理的决定.

Answer 3

关系可以在维持一个商业逻辑层.除非你能100%毫无疑问地保证你的BLL是无错误的,否则你就没有数据完整性.你不能保证.

此外,如果另一个应用程序将触及您的数据库,则不需要遵循(读取:重新实现,可能以一种微妙的方式)BLL中的规则. 它可能会破坏数据,即使你以某种方式设法成为地球上3个程序员之一来编写无错误的代码.

同时,数据库为每个人强制执行相同的规则 - 数据库强制执行的规则在更新时不太可能被忽略,因为数据库不允许这样做.

Answer 4

有听丹·普里切特,技术研究员在易趣上为什么某些数据库结构,如交易和参照完整性不教科书可能表明他们应该是任务......它归结为数据类型,查询的数量和业务需求.平衡这些,它将引导你务实的解决方案,而不是教条的答案......

不过,千万不能假定保持关系的BLL将保护您的数据.您不能保证未来的开发人员不会因为"性能"原因而暴露出绕过BLL的新API,或者对您的架构缺乏了解......

Answer 5

问题所基于的性能假设通常是不正确的。通常，如果您要求强制执行RI，那么数据库是最有效的执行位置，而不是应用程序-否则，应用程序必须重新查询更多数据，才能在数据库外部验证RI。

而且，数据库中的RI约束对于查询优化器很有用，它可以使其他查询更加高效。应用程序中的完整性约束无法实现这一目标。

最后，在每个应用程序中维护完整性约束的成本通常比在一个地方进行一次更为昂贵和复杂。