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

尽管我的目标是MySQL/PHP，但为了回答我的问题，我想将其应用于与现代编程语言结合使用的任何关系数据库。另一个假设是，该语言正在利用一个现代框架，该框架在某种程度上可以隐式地处理外键约束，也可以显式地处理外键约束

我的问题：

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

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

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

---

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

您对数据库设计和外键概念的总体熟悉程度如何？FK是一个表中的列，用于标识另一个表中的行。（我很确定你们已经知道了。）所以FK约束是存在于DB中的东西，而不是应用程序中的东西。管理应用程序中的FK约束需要手动编码数据库中已有的功能。那你为什么要做这些体力劳动呢？此外，由于所有额外的手动编码，数据库/应用程序的交互和开发要困难得多

IMHO的最佳实践是将这些工具用于其创建目的。DB负责FKs引用完整性，应用程序不需要关心DBs的内部功能。然而，如果引用完整性是您主要关心的问题，并且您正在使用MySQL和MyISAM引擎，而MyISAM引擎不支持，那么您必须手动签入应用程序（或者可能使用我不熟悉的DB触发器）。请记住，当您在应用程序中执行所有类型的检查时，您仍然必须访问数据库，因此，如果数据库能够处理引用完整性检查，那么您将使用比实际需要更多的资源。（当然，简单的解决方案是开始使用，但在这个答案变得过于面向产品之前，我将在这里停止）

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

你不必去想它

您不必手动编写任何额外的代码

应用程序使用更少的资源，包含更少的代码，因此

。。。维护和开发数据库和应用程序要容易得多（例如，应用程序开发人员不需要如此深入地理解面向数据库的概念和功能，让数据库专家进行FK等思考……）

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

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

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

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

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

除此之外，所有客户机都必须遵守相同的“锁定协议”（一个行为不端的客户机足以破坏数据）。如果有多个级别的嵌套FK或菱形FK，复杂性会迅速增加。即使您在触发器中实现了引用完整性，您也只解决了“一个行为不端的客户机”问题，但其余的问题仍然存在

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

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

您应该始终使用数据库级FKs。如果有利于您的用户体验，您也可以使用应用程序级“预检查”（即，您不想等到实际插入/更新/删除时才警告用户），但您应该始终编写代码，就好像插入/更新/删除可能失败一样，即使您的应用程序级检查已通过

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

如前所述，始终使用数据库级FKs。或者，您也可以使用应用程序级FKs“在其上”

---

另见：

在数据库中创建FK约束的优缺点是什么 而不是在应用程序级别管理它们

使用db强制FKs的一些优点：

将schmea与代码分离

使应用程序代码更小

程序员没有机会弄乱FK规则

强制与db集成的其他应用程序遵循fk规则

db强制FKs的一些缺点

如果你有特殊情况，不容易打破

如果数据无效