参考数据完整性：必要性，美好或旧帽子？

Question

在我看来，像Rails这样的框架鼓励将大量逻辑（甚至是约束和外键之类的东西）移出数据库。为了更好，因为它更易于管理且易于更改。即便如此，某些操作更容易更快，或者只是在SQL中才能实现。

最近MongoDB，Cassandra等noSQL数据库普及的爆炸式增长已经改变了数据库开发最佳实践的方法。

我的问题：参考数据完整性不再是必需品吗？

我意识到这通常归结为选择最适合这项工作的工具，但让我们排除金融应用程序和类似类型的应用程序，其中交易是必须的，并专注于更赚钱但不需要银行业务的更典型的应用程序级别的完整性。

参考数据完整性有多大必要？有人可以列出他们不使用时遇到的一些问题吗？

使用像PostgreSQL这样的数据库来获取更多关键数据，而MongoDB是用于不那么重要但要求很高的数据的智能策略吗？您如何建议准确定义哪些数据“关键”以及哪些数据“非关键？”

Answer 1

我认为这里的问题和大多数答案似乎都在说同样的事情：数据完整性（RI只是数据完整性的一个常见方面）绝对是必要的，并且仍然像以往一样重要。由于对治理，监管和数据保护的担忧日益增加，今天的数据完整性可能比过去更加重要。

恰巧人们发现DBMS没有提供他们需要的设施，因此他们希望在其他地方实施完整性规则。这很奇怪，因为毕竟DBMS最接近数据，因此应该最有效地实施业务规则。声明性规则应该比程序性规则更容易维护和验证。在数据库中集中维护规则也应该比在许多其他层和应用程序中分发规则更具成本效益。

我的结论是，如果这些事情不是证明对某些人来说是真实的，那么这实际上说明了当今数据库软件的不足之处。 不暗示诚信是不重要的 - 恰恰相反。

Answer 2

我认为你对两个数据存储的最终评论是大多数新的中型应用程序的未来。一个后端具有引用完整性，用于连接站点的核心组件，另一个用于更大的Internet规模数据。

像eBay这样的传统公司不应该被用作比较，因为他们有资源进行严格的质量保证，并思考开发人员所做的一切。典型的中小型创业公司没有这些资源，并且通过参照完整性将关键数据保存在商店中，可以防止很多应用程序存在缺陷，无法长时间静默地放置在您的站点中。

查看Django的support for multiple databases。请记住，从ACID数据存储区移动到CRUD数据存储区比使用其他方式更容易。

Answer 3

如果要关联并引用数据，则引用完整性始终是有效的关注点。现代问题不是是否有必要，而是以传统的sql数据库方式管理它，通过程序员和数据库管理员管理的索引来验证外键字段。为对象访问量身定制的简单数据库可能隐藏传统的数据完整性方法，或者可能允许以编程方式管理问题作为例外，或者可以手动管理此类问题。

话虽如此，传统方法适用于大多数应用程序（虽然显然不是eBay）。在您遇到难以恢复的完整性问题之前，参照完整性似乎很愚蠢。由于实现起来很简单，因此您应该从它开始，只有在性能需求变得明显无法通过其他方式满足时才将其删除。

对于mongo，在使应用程序更易于实现和维护时使用它。如果需要，你绝对可以同时使用它们。

Answer 4

我曾在一家数据库庞大的公司（ebay.com）工作过。我们不应该在数据库中使用任何引用完整性。这一限制措施已经到位，牢记性能因素。我们甚至不会在ORM（对象关系映射）级别中定义任何内容。一切都必须在逻辑上处理。我知道它有点难以想象，但仍然可以提供更好的性能。

现在针对您的问题，在ORM级别发生了太多的抽象，人们甚至不关心数据库端的内容。至少新编写的代码几乎不用编写触发器，直接在数据库（例如oracle）中声明引用完整性，你可以通过编写存储过程来做很多事情。但是仍然人们更喜欢并且更容易在ORM级别对所有内容进行编码。所以，IMO，我觉得它变成了一顶旧帽子。

Answer 5

我认为另一件需要考虑的事情是应用程序和数据存储的生命周期。如果数据存储对业务有用，则可能由多个应用程序访问和/或具有到其他数据存储的接口。参考完整性所包含的数据越接近接口或其他不良更新的风险越小。

虽然您现在正在使用的应用程序现在可能有7年左右的接口？ （显然，平均业务应用程序保留7年）当业务增长时，将使用其他工具（例如，通过实施到同一业务或通过收购另一个业务）

Answer 6

如今，您的问题的答案不是通用的，而是取决于应用程序和业务需求。

您的问题的答案实际上是：总是考虑您的数据完整性策略

例如：

• 在欧洲，我们有GDPR。您不允许将个人数据保留超过必要的时间，因此在某些应用程序中，您希望能够删除完整的客户记录，同时保留订单数据（另一种方法是使客户记录匿名）
• 当nosql数据库最适合您的应用程序时，您将没有数据库提供的引用数据完整性，因此您将必须在应用程序中进行管理。您可以选择在应用程序中允许/支持断开的引用，也可以在应用程序级别实现引用完整性。
• 在nosql中，引用完整性也是模式设计的一部分。存储订单时，对订单行的引用将不是引用而是嵌入的，从而避免了引用完整性问题。

Answer 7

几年后，我想提供自己的答案：

为工作使用正确的数据库，但是对于许多工作负载，传统的RDBMS（关系数据库管理系统）仍然是不错的选择。并且由于大多数数据库都提供了进一步增强架构规则的功能，因此最好使用它们。在应用程序层执行诸如唯一验证或外键验证之类的操作需要不必要的来回操作，并且在存储结构化的关系数据时，数据库（如postgresql）无法做到最好。