Database 是否应该强制执行引用完整性？

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

---

因为关系无论如何都是在业务逻辑层中维护的，所以对于db来说这只是多余的。你对此有什么想法？

数据库负责数据。就这样。句号

如果引用完整性没有在数据库中完成，那么它就不是完整性。这只是相信人们不会做坏事，在这种情况下，您甚至不应该担心密码保护您的数据：-）

---

谁能说你不会让别人编写他们自己的JDBC连接客户端来完全破坏数据，尽管你的业务层是精心设计的，没有bug（事实上，它可能不会完全没有bug是另一个问题，要求DB保护自己）.

关系可以在业务逻辑层中维护。除非您可以毫无疑问地100%保证您的BLL是并且永远是无bug的，否则您就没有数据完整性。你不能保证

此外，如果另一个应用程序曾经接触过您的数据库，则不需要遵循BLL中的规则（读：重新实现，可能是以一种微妙的错误方式）。它可能会破坏数据，即使你以某种方式设法成为地球上三个编写无bug代码的程序员之一

同时，数据库对每个人都强制执行相同的规则，而且数据库强制执行的规则在您更新时不太可能被忽略，因为数据库不允许它。

请与Dan Pritchett联系，eBay的技术研究员，解释为什么某些数据库结构（如事务和引用完整性）不是教科书可能指出的要求。。。这取决于数据类型、查询量和业务需求。平衡这些因素，它将引导你找到务实的解决方案，而不是教条式的答案

---

但是，不要假设在BLL中保留关系将保护您的数据。您不能保证未来的开发人员不会因为“性能”原因，或由于对您的体系结构缺乏了解而公开绕过BLL的新API…

这取决于数据，如果其高度事务性的数据（如业务事务）以及其他频繁更新的地方，那么在数据库中强制执行业务规则是极其重要的。。但对于其他方面来说，性能影响可能并不值得

首先，要让它真正正常工作几乎是不可能的。为了有机会正常工作，您需要将大量级联修改打包为事务，这样在更改数据库的一部分时，不会出现不同步的情况，但仍在更新依赖于第一部分的其他内容。这意味着应该简单且只知道业务逻辑的代码突然需要了解各种并发性问题

第二，保持it正常工作几乎是不可能的——每次有人接触到业务逻辑时，他们都需要再次处理这些并发性问题

第三，这使得引用完整性很难理解——将来，当有人想要了解您的数据库结构时，他们将不得不从您的业务逻辑中对其进行反向工程。在数据库中，它是独立的，因此您需要关注的只是引用完整性，而不是所有不相关的问题。您有（例如）直接的逻辑链，显示对特定字段的修改将触发什么。至少对于相当多的数据库，该逻辑可以自动提取并转化为相当有用的文档（例如，显示依赖关系的树形图）。从BLL中提取同类信息更可能是一个相当严肃的项目

---

当然，在另一个方向上也有一些观点，并且有理由手工制作所有这些——可伸缩性和性能是最明显的。然而，当你走这条路的时候/如果你走这条路的话，你应该意识到你为了获得那样的表现而放弃了什么。在某些情况下，这是一个值得权衡的问题，但在其他情况下则不然，您需要信息来做出合理的决定。

作为问题基础的性能假设通常是不正确的。通常，如果您需要强制执行RI，那么数据库是执行RI的最有效的地方，而不是应用程序-否则应用程序必须重新查询更多数据，以便能够在数据库之外验证RI

此外，数据库中的RI约束对于查询优化程序非常有用，可以提高其他查询的效率。应用程序中的完整性约束无法实现这一点

---

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

如果您在业务层维护关系，您可以保证几年后数据库中会有坏数据。业务层是最不可能做到这一点的地方

---

此外，当您用其他内容替换业务层时，您必须重新定义所有这些内容。datbase通常比它们为之编写的原始应用程序要长很多年，将正确的关系和约束放在它们所属的datbase中

paxdiablo和dportas说的话。还有我的两分钱。还有两个其他考虑因素

为了验证新插入的引用完整性，必须对数据库进行探测，以验证引用是否有效。您刚刚取消了导致您希望在应用程序中强制实施完整性的性能增益。实际上，让DBMS执行r会更快