数据库FK约束与可编程FK约束

Question

虽然我的目标是MySQL/PHP，但为了我的问题，我只想将其应用于与现代编程语言结合使用的任何关系数据库。另一个假设是，该语言正在利用一个现代框架，在某种程度上，该框架将隐式地处理外键约束，或者有明确地这样做的手段。

我的问题：

• 与在应用程序级别管理FK约束相比，在数据库本身中创建FK约束的利弊是什么？
• 从设计的角度来看，它们是否应该一起使用，还是会引起冲突？
• 如果不应在一起使用，在使用哪一种方法方面，什么是“最佳做法”？

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

Answer 1

与在应用程序级别管理FK约束相比，在数据库本身中创建FK约束的利弊是什么？

在并发环境中，很难在应用程序代码中实现引用完整性，这样既正确又具有良好的性能。

除非您非常小心地使用锁定，否则您将面临竞争条件，例如：

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

为了弥补这一点，您可以从两个事务中锁定父行，但与DBMS本身中实现的高度优化的FK相比，它的性能可能更低。

除此之外，所有客户端都必须遵守相同的“锁定协议”(一个行为不当的客户端就足以中断数据)。如果有几个层次的嵌套FKs或菱形FKs，那么复杂性就会迅速提高。即使您在触发器中实现了引用完整性，您也只是在解决“一个行为不当的客户端”问题，但其余的问题仍然存在。

数据库级FKs的另一个优点是，它们通常支持引用操作，比如删除级联。所有这些都是简单和自文档化的，不像应用程序代码中隐藏的引用完整性。

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

您应该始终使用数据库级别的FKs。您也可以使用应用程序级别的“预检查”，如果这有利于您的用户体验(即，您不希望等到实际的插入/更新/删除来警告用户)，但是您应该始终编写代码，就像插入/更新/删除可能会失败一样，即使您的应用程序级检查已经通过。

如果不应在一起使用，在使用哪一种方法方面，什么是“最佳做法”？

正如我所说，始终使用数据库级别的FKs。或者，您也可以使用应用程序级别的FKs“在它们的顶部”。

另见：Sql -间接外键

Answer 2

你对数据库设计和外键概念有多熟悉？FK是一个表中标识另一个表中某一行的列。(我很肯定你已经知道了。)因此，FK约束是存在于DB中的，而不是应用程序中的。在应用程序中管理FK约束需要对DB中已经可用的功能进行手动编码。那你为什么要做那些体力活呢？另外，由于额外的手工编码，DB/应用程序的交互和开发要困难得多。

IMHO的最佳实践是使用工具来完成所创建的任务。DB负责FKs的引用完整性，应用程序不需要关注DBs的内部功能。但是，如果引用完整性是您的主要关注点，并且您使用的是MySQL和不支持FK约束的MyISAM引擎，那么您必须在应用程序中进行一些手动检查(或者使用我不熟悉的DB触发器)。请记住，当您在应用程序中执行所有类型的签入时，您仍然必须访问DB，因此，如果DB能够处理引用完整性检查，那么您使用的资源比真正需要的资源还要多。(当然，简单的解决方案是开始使用InnoDB引擎，但在这个答案过于面向产品之前，我将在此结束)。

因此，让DB处理FK约束的一些优点是：

1. 你没必要去想。
2. 你不必手动编码任何额外的东西。
3. 应用程序使用的资源更少，包含的代码也更少，因此.
4. ..。维护和开发DB和应用程序都要容易得多(例如，应用程序开发人员不需要如此深入地理解面向数据库的概念和功能，让DB专家进行FK等方面的思考……)。

Answer 3

与在应用程序级别管理FK约束相比，在数据库本身中创建FK约束的利弊是什么？

使用数据库执行的FKs的一些优点：

1. 从密码中分离出来。
2. 使应用程序代码更小
3. 程序员没有机会破坏FK规则。
4. 强制与数据库集成的其他应用程序遵循fk规则。

有数据库强制FKs的一些缺点。

1. 如果你有特殊情况，很难打破
2. 如果数据无效，则可能引发错误。应用程序应该被编码，以便优雅地处理那些错误(特别是批处理错误)。
3. 定义具有引用完整性规则的FK必须仔细定义和编码。您不希望级联删除1000000行联机。
4. 它们会导致隐式检查，即使您不希望发生这种检查，因为您知道父行必须存在。这可能会对性能产生微不足道的影响。在批量加载和OLAP/数据仓库系统中加载大量数据时，性能是一个问题。在加载过程中，通常会使用特殊的加载工具，并禁用数据库强制的FKs等约束。

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

你可以把它们放在一起是有原因的。正如我前面提到的，您的数据中可能有无法定义FKs的特殊情况。此外，也有某些情况，例如FKs无法处理的表之间的多到多自引用关系(至少对某些db引擎而言)。