确保与关系数据库的一致性，无需外键

Question

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

  

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

我们是否需要定期检查此类应用程序的一致性？在这种情况下，应该为每个请求做出响应 - 没有无效的外键并在应用层中同时纠正它。

Answer 1

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

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

关系数据库基本上是一个大型数学引擎，可以对大型数据集执行集合（实际上是由于对实际数据完整性问题的让步）。随着集合的增长，验证数据完整性的能力降低，直到某个时候根据随后的集合模型验证数据的整体有效性。我曾在PostgreSQL数据库中使用过不可能出现限制的数据库，所以在某些领域我们不得不承认存在参照完整性违规行为。

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

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

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

然而，

参照完整性约束不是免费的。使用它们有两个重要的缺点，有时会导致开发人员决定不这样做。

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

值得进一步指出的是，Rails指南并未就此权衡提供可靠的指导。像许多ORM一样，Active Record提供了在应用程序中解决这个问题的工具，我发现很多人在数据库中使用外键的例子，并且没有人说＆＃34;不使用它们。＆＃34;

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

当然，关注和进一步的缓解措施取决于重要性和进一步使用数据。影响较小的数据集（它只是应用程序的私有数据存储（常规路径方式））与使用的影响较大的数据存储具有相同的含义，后者旨在用于以后的决策支持。因此，重复读取使用是决定是否需要定期重新扫描的重要问题。

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

因此，在回答您的问题时，您可能需要也可能不需要。但是你应该做一个风险评估并决定做什么。这样的风险评估不仅会在当下，也会在将来引导这一决定。

作为旁注

您可以使用外键在使用挂钩等时保持一致性，以确保在ActiveRecord组件中正确处理逻辑。即而不是使用由钩子处理的ON DELETE CASCADE。