ruby-on-rails - 在没有外键的情况下确保与关系数据库的一致性

Question

我见过像 discourse 这样的例子关系数据库中的表没有外键。虽然 RDB 的其他租户仍在使用，如 CONSTRAINTS、INDEXES、FULLTEXTSEARCH 等。但根据 Rails Active record guidelines，外键已被删除。

https://meta.discourse.org/t/foreign-key-constraints-in-db/2642

我们是否需要定期检查此类应用程序的一致性？在那种情况下，是否应该为每个请求-响应完成不存在无效外键的操作，并在应用层同时更正它。

Answer 1

好的，首先要了解的是为什么我们通常在数据库中放置这样的约束。第二点是为什么有些人不喜欢这个。第三个是不这样做的后果。

为什么我们将 RI 检查放在数据库中

关系数据库基本上是一个大型数学引擎，对大型数据集执行集合(好吧，实际上是袋子，由于对现实世界数据完整性问题的让步)操作。随着数据集的增长，验证数据完整性的能力会降低，直到在某个时候，人们无法根据所遵循的集合模型验证数据的整体有效性。我曾使用过无法进行约束的 PostgreSQL 数据库，因此在某些领域我们不得不接受存在引用完整性违规的情况。

在一个软件项目拥有数据库的情况下管理参照完整性的问题可能很棘手，但当许多不同的程序可以读取或写入相同的数据时，它们会变得更糟。这变得更糟，因为规范化和封装问题随着读取(更糟糕的是，写入)数据的路径数量的增加而增加。

因此，确保每次写入都不会违反参照完整性是数据管理中的一项重要工具。

为什么有些人避免在数据库中检查 RI

然而，引用完整性约束并不是免费的。使用它们有两个重要的缺点，有时会导致开发人员决定不使用它们。

1. 参照完整性检查不是免费的。它们确实会影响数据库性能，而且数据库通常被认为是系统中可扩展性最低的部分，并且
2. 他们划分逻辑，将其放置在不同的位置，并将数据模型逻辑与应用程序逻辑分开。虽然这种关注点分离通常是可取的，但在单个应用程序拥有一个数据库的情况下，它有时(但不总是!)被认为是不太理想的权衡。

值得进一步注意的是，Rails 准则并未就此权衡提供可靠的指导。与许多 ORM 一样，Active Record 提供了在应用程序中解决此问题的工具，我发现很多人在数据库中使用外键的例子，但没有人说“不要使用它们”。

避免在数据库中进行 RI 检查的担忧

当然，担忧和进一步缓解措施取决于数据的重要性和进一步使用。影响较小的数据集只是应用程序的私有(private)数据存储(正常的 Rails 方式)与使用的影响较大的数据存储(旨在稍后用于决策支持)具有不同的含义。因此，重复读取使用是决定是否需要定期重新扫描的重要问题。

第二个问题是替代写入源。一般来说，在这个模型中，最重要的问题是防止在使用这些特定的 ActiveRecord 使用类之外的其他写入源。

因此，在回答您的问题时，您可能需要也可能不需要。但是您可能应该进行风险评估并决定要做什么。这样的风险评估不仅会指导当前的决策，也会在未来指导决策。

作为旁注

您可以使用外键来保持一致性，同时使用钩子(Hook)等来确保逻辑在 ActiveRecord 组件中得到正确处理。 IE。而不是使用 ON DELETE CASCADE，而是使用 Hook 处理。