在我看来，像 Rails 这样的框架鼓励将很多逻辑，甚至是约束和外键之类的东西从数据库中移出。变得更好，因为它更易于管理且易于更改。即便如此，一些操作更容易更快，或者只是在 SQL 中才有可能。
最近 MongoDB、Cassandra 等 noSQL 数据库的流行爆炸式增长，更彻底地改变了数据库开发中最佳实践的方法。
我的问题：参考数据完整性不再是必需品吗？
我意识到这通常归结为选择最适合这项工作的工具，但让我们排除金融应用程序和必须拥有交易的类似类型应用程序，并专注于更典型的赚钱但不需要银行级别完整性的应用程序.
参考数据完整性有多必要？有人可以列出他们在不使用它时遇到的一些问题吗？
使用 PostgreSQL 之类的数据库存储更关键的数据，使用 MongoDB 存储不太关键但要求高的数据是明智的策略吗？您如何建议准确定义哪些数据是“关键的”，哪些是“非关键的”？
我认为这里的问题和大多数答案似乎都在说同样的事情：数据完整性（RI 只是数据完整性的一个常见方面）绝对是必要的，并且在今天仍然像以往一样重要。由于对治理、监管和数据保护的担忧日益增加，今天的数据完整性可能比过去更加重要。
碰巧人们发现 DBMS 没有提供他们需要的设施，因此他们希望在其他地方实施完整性规则。这很奇怪，因为毕竟 DBMS 最接近数据，因此应该最适合有效地实施业务规则。声明性规则应该比程序性规则更容易维护和验证。在数据库中集中维护规则也应该比在许多其他层和应用程序中分布规则更具成本效益。
我的结论是，如果这些事情对某些人来说不是真的，那么这实际上说明了当今数据库软件的缺陷。这并不意味着完整性不重要——恰恰相反。
我认为您对拥有两个数据存储的最后评论是大多数新中型应用程序的未来。一个后端具有参照完整性，用于连接站点的核心组件，另一个用于更大的 Internet 规模数据。
不应将像 eBay 这样的传统公司用作比较，因为它们有资源进行严格的 QA 并考虑开发人员所做的每件事的含义。典型的中小型初创公司没有这些资源，并且将关键数据保存在具有引用完整性的存储中可以防止许多应用程序缺陷能够在您的站点中长时间静默。
查看 Django对多个数据库的支持。请记住，从 ACID 数据存储迁移到 CRUD 数据存储比其他方式容易得多。
如果您想关联和引用数据，引用完整性将始终是一个有效的关注点。现代的问题不是是否有必要，而是是否以传统的 sql 数据库方式进行管理，即通过程序员和数据库管理员管理的索引来验证外键字段。为对象访问量身定制的简单数据库可能会隐藏传统的数据完整性方法，或者可能允许以编程方式将问题作为异常进行管理，或者可以手动管理此类问题。
话虽这么说，传统方法适用于大多数应用程序（尽管显然不是 eBay）。在您遇到难以恢复的完整性问题之前，参照完整性似乎很愚蠢。由于实现起来很简单，因此您应该从它开始，并且只有在性能需求变得明显而无法通过其他方式满足时才将其删除。
至于 mongo，当它使应用程序更易于实现和维护时使用它。如果需要，您绝对可以同时使用两者。
我曾在一家数据库庞大的公司 (ebay.com) 工作过。我们不应该在数据库中使用任何引用完整性。仅考虑性能因素就实施了此限制。我们甚至不会在 ORM（对象关系映射）级别定义任何内容。一切都必须有逻辑地处理。我知道这有点难以想象，但这仍然是提供更好性能的原因。
现在对于您的问题，由于在 ORM 级别发生了太多抽象，人们甚至都不关心数据库端发生了什么。至少新出现的编码几乎不关心编写触发器，直接在数据库（例如 oracle）中声明引用完整性，您可以通过编写存储过程来做很多事情。但是人们仍然喜欢并且感觉更容易在 ORM 级别编写所有代码。所以，IMO，我觉得它正在成为一个老帽子。
我认为要考虑的另一件事是应用程序和数据存储的生命周期。如果数据存储对业务有用，则可能会被多个应用程序访问和/或具有与其他数据存储的接口。参照完整性越接近数据，接口或其他东西进行错误更新的风险就越小。
虽然你现在正在开发的应用程序现在可能有接口，但 7 年后呢？（显然，平均业务应用程序保留 7 年）当业务增长时，将使用其他工具（例如，通过实施到同一业务或通过收购另一业务）
几年后，我想提供我自己的答案：
为工作使用正确的数据库，但对于许多工作负载，传统的 RDBMS（关系数据库管理系统）仍然是一个不错的选择。而且由于这些数据库中的大多数都提供了进一步增强模式规则的功能，因此最好使用它们。在应用程序层执行诸如唯一验证或外键验证之类的操作需要不必要的来回操作，并且不会让数据库（如 postgresql）在存储结构化的关系数据时做它最擅长的事情。
如今，您的问题的答案不是通用的，而是取决于应用程序和业务需求。
您的问题的答案实际上是：始终考虑您的数据完整性策略
例如：