今天早些时候，我与我的专业同行就我们公司数据库中的外键话题引发了一场相当意外的辩论。简而言之，一位比我年长的软件工程师说他不喜欢我对我们的一个存储库所做的提交，因为我在两个表之间实现了外键关系。他的论点是他不喜欢外键，因为它们限制了可以插入数据库的数据，他认为这会使数据库更难使用。（注意：他的论点一般反对外键，而不仅仅是我在我们的应用程序中提出的轶事外键约束。他认为外键约束是现代关系数据库系统中的一个设计缺陷。）
此时，我完全措手不及，我们的老板暂时选择站在高级开发人员一边，要求我从我正在处理的错误修复的实现中删除外键。我正在修复的错误实际上源于使我们的 ORM 感到困惑的关系不一致（这本身还有一些不足之处，但这是一个不同的故事），虽然我试图向我的团队解释这一点，但每个人都站在高级dev & 我被告知要回到绘图板并重新实现我的数据库修复，而不依赖于外键约束。换句话说，我被要求在没有 RDBMS（posgres，如果重要的话）的内置关系管理工具的情况下进行关系管理。
我重申这不是修复错误的正确方法，此时我的老板告诉我讨论占用了太多时间，如果我想辩论正式 FK 约束的优点，我需要以后再做……我打算这样做，但我也觉得我的任务是争论为什么水是湿的。
当我进入这场辩论时，我想用尽可能多的事实来支持外键的使用。我知道实施合理的 FK 约束：
......但我想知道在这个主题上是否还有其他我可能遗漏的要点，我应该用这些要点来应对这场辩论。我应该确保向我的老板和同事提出哪些其他好处？（或者真的有范式转变远离 FK 约束，当它发生时我一直把头埋在石头下？）