Hans-Juergen Schoenig：PostgreSQL中的外键：循环依赖
内容提要
PostgreSQL外键可保障数据完整性，但部门与员工互相引用会形成循环依赖，导致两表都无法插入数据。解决办法是使用INITIALLY DEFERRED，将外键检查延迟到COMMIT时执行，这样在同一事务内可按任意顺序插入，只要提交前满足所有约束即可。
延伸解读
循环依赖的典型场景
文章以部门和员工互相引用为例：每个部门需要一位领导，每位员工需要所属部门。这种设计导致两个表的外键互相指向对方，形成循环依赖。在默认情况下，无论先向哪个表插入数据，都会因违反外键约束而失败，使数据无法录入。这提醒我们在设计数据库模式时，需警惕这种相互依赖的关系。
延迟约束的解决机制
PostgreSQL 提供了 INITIALLY DEFERRED 选项，将外键检查从语句执行时推迟到事务提交时。这样，在同一个事务内，可以按任意顺序插入数据，只要在 COMMIT 前所有约束都得到满足即可。这为解决循环依赖提供了简洁而有效的方法，无需改变表结构或禁用约束。
使用延迟约束的注意事项
虽然 INITIALLY DEFERRED 能解决插入顺序问题，但需注意它仅在同一事务内有效。如果事务提交时约束仍未满足，整个事务将回滚。此外，延迟检查可能对性能有轻微影响，尤其是在高并发场景下。因此，应确保事务逻辑正确，避免长时间持有未提交的事务。
Q&A
PostgreSQL 外键的循环依赖是什么？
循环依赖是指两个表互相引用对方的外键，导致无法插入数据。例如部门表需要员工ID作为领导，员工表需要部门ID，两者互相依赖，插入任何一张表都会违反外键约束。
为什么部门表和员工表互相引用时无法插入数据？
因为外键约束要求被引用的记录必须存在。插入部门时需要员工ID，但员工尚未插入；插入员工时需要部门ID，但部门尚未插入。无论先插入哪张表，都会违反外键约束。
如何解决 PostgreSQL 外键的循环依赖问题？
使用 INITIALLY DEFERRED 约束。将外键检查延迟到事务提交时进行，这样在事务内可以按任意顺序插入数据，只要提交前满足所有约束即可。
INITIALLY DEFERRED 在 PostgreSQL 中是如何工作的？
INITIALLY DEFERRED 告诉 PostgreSQL 不在写操作时立即检查约束，而是延迟到 COMMIT 时检查。这样在事务内可以任意顺序操作，只需确保提交时所有约束都满足。
使用 INITIALLY DEFERRED 后，插入数据的具体步骤是什么？
在创建外键约束时加上 INITIALLY DEFERRED，然后在一个事务中先插入部门（领导ID暂为NULL），再插入员工（引用部门ID），最后更新部门设置领导ID，提交事务即可。
使用 INITIALLY DEFERRED 处理循环依赖有什么好处？
可以在事务内以任意顺序插入数据，无需担心插入顺序，只要在提交前满足所有外键约束即可，从而解决循环依赖导致的插入失败问题。
