数据库外键约束与编程外键约束

Question

虽然我的目标是 MySQL/PHP，但出于我的问题，我想将其普遍应用于与现代编程语言结合使用的任何关系数据库。另一个假设是该语言正在利用现代框架，该框架在某种程度上会隐式处理外键约束或有办法显式处理。

我的问题:

• 与在应用程序级别管理它们相比，在数据库本身中创建 FK 约束有哪些优缺点？

• 从设计的角度来看，它们应该一起使用还是会导致冲突？

• 如果它们不应该一起使用，关于使用哪种方法，什么被认为是“最佳实践”？

注意:这是一个设计理论问题。由于可用于满足实现的技术种类繁多，我对有关实现的任何细节都不感兴趣。

Answer 1

What are the pros and cons of creating FK constraints in the database itself as opposed to managing them at the application level?

在并发环境中，在应用程序代码中实现参照完整性是非常困难的，因此它既正确又具有良好的性能。

除非您非常小心地使用锁定，否则您很容易遇到竞争条件，例如:

• 假设当前父表中有一行，子表中没有相应的行。
• 事务 T1 在子表中插入一行，但尚未提交。它可以这样做，因为父表中有相应的行。
• 事务 T2 删除父行。它可以这样做，因为从它的角度来看没有子行(T1 尚未提交)。
• T1 和 T2 提交。
• 此时，您有一个没有父行的子行(即引用完整性损坏)。

为了解决这个问题，您可以锁定两个事务的父行，但与在 DBMS 本身中实现的高度优化的 FK 相比，这可能会降低性能。

最重要的是，您的所有客户端都必须遵守相同的“锁定协议(protocol)”(一个行为不当的客户端足以破坏数据)。如果您有多层嵌套 FK 或菱形 FK，复杂性会迅速增加。即使您在触发器中实现参照完整性，您也只是解决了“一个行为不当的客户端”问题，而其余问题仍然存在。

数据库级 FK 的另一个好处是它们通常支持引用操作，例如 ON DELETE CASCADE。与隐藏在应用程序代码中的引用完整性不同，所有这一切都很简单且可以 self 记录。

From a design standpoint, should they ever both be used together or would that cause conflict?

您应该始终使用数据库级 FK。如果这有利于您的用户体验，您也可以使用应用程序级别的“预检查”(即您不想等到实际的 INSERT/UPDATE/DELETE 来警告用户)，但您应该始终像 INSERT/即使您的应用程序级检查已通过，UPDATE/DELETE 也可能会失败。

If they should not be used together, what is considered the "best practice" in regards to which approach to use?

正如我所说，始终使用数据库级 FK。 可选，您也可以在它们“之上”使用应用程序级 FK。

---

另请参阅:Sql - Indirect Foreign Key