数据库中没有外键约束的 9 个原因

我最近与一些DBA和架构师发生了争执，他们对一些数据库没有外键感到震惊，并声称这是一个设计缺陷，不应该发生。如果是这样，应该立即修复。我想对此进行反驳。我的经验告诉我，许多数据库（我使用过的大多数数据库）都不包含外键，而且这并不总是一件坏事。在本文中，我想重点介绍为什么会这样的原因。

为什么这是一个问题？

1. 潜在的数据完整性问题，呃

缺少外键的明显问题是数据库无法强制实施引用完整性，如果在较高级别上未正确处理它，则可能导致数据不一致（子行没有相应的父行）。

2. 表格关系不明确

数据库中缺少外键的另一个不太明显的负面影响是，不知道架构的人很难找到正确的表并弄清楚表之间的关系。这可能会导致从数据库进行查询和报告的严重问题。

为什么数据库没有外键？

让我们来看看数据库没有外键的原因。但首先，一个简短的免责声明（因为文章引发了LinkedIn团体的一些争议）：

下面提出的理由绝不是鼓励不要在数据库中使用外键约束。它只是我在各种来源（主要是互联网论坛）中找到的原因的集合，为什么许多开发人员，架构师或供应商不使用它们。我个人（以及许多其他有经验的数据库专业人员）建议尽可能使用它们（它们不会造成比解决更多的问题）。我让你们决定这些原因中哪一个实际上是一个好理由。有关缺少 FK 导致的问题的更多信息，请参阅另一篇文章。

1. 性能

在表上使用活动外键可以提高数据质量，但会损害插入、更新和删除操作的性能。在这些任务之前，数据库需要检查它是否不违反数据完整性。这就是为什么一些架构师和DBA完全放弃外键的原因。在数据仓库和分析数据库中尤其如此，它们不以事务方式（一次处理一行）而是批量处理数据。在数据仓库和商业智能中，性能就是一切。

2. 遗留数据

许多数据库在设计时需要存储来自旧数据库和源的旧数据，这些数据库和源可能对数据质量和完整性没有那么严格。为了能够包含旧的脏数据，架构师可以选择a）清理和转换遗留数据（昂贵的练习）或b）放弃在数据库级别强制实施引用完整性。一些打包的 ERP 和 CRM 应用程序也使用此方法。

 

3. 全表重新加载

某些数据库（如数据仓库、临时数据库或接口数据库）需要经常从外部源重装数据。这会导致数据在重新加载时不一致（子表可能已完全加载，而父表为空）。这可以通过在重新加载时禁用密钥来绕过。但是，这引入了额外的逻辑和复杂性以及另一个故障点。如上所述，对性能有负面影响。通常，成本大于收益，开发人员只是不打扰关键。

4. 更高层次的框架

某些应用程序使用编程框架，在物理数据库之上创建另一个逻辑层。开发人员不使用插入或更新语句来修改数据，而是使用 API，或者框架在后台执行所有操作。在ORM（对象关系映射）框架或像Ruby这样的框架中就是这种情况。这些工具负责参照完整性，并与 RDBMS 一起创建更高级别的数据库引擎。这些框架可以自己创建数据库表，而并不总是创建外键。使用此类工具的开发人员很少干扰自动生成的架构，并使其没有密钥。

5. 跨数据库关系

这不是数据库没有外键的正确原因，而是为什么它可能缺少一些外键的正确原因。某些数据库跨越更多的物理数据库甚至引擎，并且从技术上讲，创建跨数据库的密钥可能是不可能的。SQL Server 是一个很好的例子 - 它不允许在同一服务器上的两个数据库之间创建密钥。这种架构在更大规模的系统中很常见。

6. 数据库平台不可知

与上一个应用程序类似，一些应用程序被设计为与数据库平台（DBMS）无关，并且能够在各种数据库（如Oracle，SQL Server，DB / 2或Sybase）上工作。这就是我读到的关于PeopleSoft（目前由甲骨文拥有）的内容。设计人员不想绑定到任何特定平台，而是将所有逻辑推送到应用层，使数据库层尽可能简单。

7. 开放变革

坚持使用Oracle，我听说过的另一个关于其应用程序的故事，这次是它自己的子级 - Oracle电子商务套件 - 是它被设计为尽可能可定制。Oracle提供了坚实的基础，并使实施团队具有弹性，可以决定设计的尽可能多的方面。至少他们是这么说的。也许原因与上一点相同，或者是下一点：

8. 懒惰的架构师

创建数据库时，如果要存储数据，则需要创建一些表和列。这是最低要求。但是，您不必创建保持数据一致性的结构，例如主键、唯一键、外键或约束。它需要一些努力，没有直接的好处。一些架构师和DBA只是忽略了这一部分。

9. 保守数据模型的秘密

也许这个很牵强，但也许有时是因为人们不希望别人太容易，知道太多。一般来说，人们希望被需要和不可替代。一个完美的不言自明的设计可能会使它们过时。但这只是我的理论。

 

结论

我希望我设法提出了合理的理由，为什么外键没有像许多人预期的那样被广泛使用。如果您知道任何其他原因或不同意我的论点，请发表评论。