【表设计】外键的取舍-分布式中逐渐消失的外键

在分布式大行其道的今天，为什么外键约束越来越少？

外键-数据链接带来强制完整性

在关系型数据库中，外键（Foreign Key）可以用于建立和强制两个表之间的数据链接。

在层次数据结构一篇的闭包表简单设计中，就有使用外键进行数据链接。
像这样：

我们很容易发现，外键最直接的体现是强制完整性，即引用表中的外键值必须先存在于被引用表。
删除被引用的行数据时，必须先删除引用表数据（级联删除）。
通过外键，我们很容易理清楚表之间的关系，即理解数据模型，且也有利于ER图的生成和可视化。

外键-强制完整性不适应微服务

分布式与微服务追求服务的自洽，要求服务具备独立性，要求架构整体具备容错，服务之间不会互相阻塞。
这些与外键的强制关联特性相冲突。
且在数据库与服务基本是N对N的环境下，数据库外键约束通常无法跨越不同的数据库实例或服务边界来强制执行。
另外数据库每次执行外键操作还需要额外的检查来验证外键约束。在高并发、高写入吞吐量的场景下，这样的额外开销可能会成为性能瓶颈。

因此，高耦合强制的外键，并不适应现在主流的微服务、分布式。

应用层处理代替外键约束

外键不合适了，但是外键要做的事情却不能不做，常见的做法是在应用层完成外键原本的工作。

• 数据链接
  在执行删除或更新操作前，应用程序代码需要检查是否存在关联数据。
  通过逻辑删除，保留数据的链接。

• 数据稽核
  建立一个稽核系统，处理数据的不一致与孤儿数据（在引用表有数据，被引用表没有数据）。