相关疑难解决方法(0)

在数据库中定义外键还是在应用程序的代码部分中定义外键更好？

我正在与我工作的公司的开发人员进行永久讨论，因为他们说最好摆脱关系数据库中的关系强制（通过 FOREIGN KEY 约束定义）以加快大型查询并获得更好的结果表现。

考虑的平台是MySQL 5.x，没有设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对我来说是不合理的。也许他们是对的，我是错的，但我没有足够的论据来讨论这种情况。

三年来，这一直是首选方法。我是这家公司的新人（只有一个月），但是，随着产品“有效”，我对增强数据库犹豫不决；尽管如此，我注意到的第一件事是加载一个页面需要 1 分钟（是的，60 秒！）。

当前状况背后的说法之一是“非规范化”数据库比规范化数据库更快，但我不相信这是真的。

大多数相关查询都包括 JOIN 操作，这使得它们在处理大量数据（数据库包含数百万行）时运行非常非常缓慢。

通常，“CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据，让我们说TableA：

• 有必要先检查在运行，如果有排之间的一些关系TableA和TableB，
• 如果“检测到”所述关系，则应用程序代码将不允许删除相关行，但是
• 如果由于某种原因应用程序代码失败，那么 DELETE 操作将“成功”，无论涉及的行和表是否存在任何关系。

题

你能帮我详细阐述一个好的、准确的和可靠的答案来丰富辩论吗？

_{注意：以前可能有人问过（并回答过）类似的问题，但我无法通过 Google 找到任何内容。}

今天早些时候，我与我的专业同行就我们公司数据库中的外键话题引发了一场相当意外的辩论。简而言之，一位比我年长的软件工程师说他不喜欢我对我们的一个存储库所做的提交，因为我在两个表之间实现了外键关系。他的论点是他不喜欢外键，因为它们限制了可以插入数据库的数据，他认为这会使数据库更难使用。（注意：他的论点一般反对外键，而不仅仅是我在我们的应用程序中提出的轶事外键约束。他认为外键约束是现代关系数据库系统中的一个设计缺陷。）

此时，我完全措手不及，我们的老板暂时选择站在高级开发人员一边，要求我从我正在处理的错误修复的实现中删除外键。我正在修复的错误实际上源于使我们的 ORM 感到困惑的关系不一致（这本身还有一些不足之处，但这是一个不同的故事），虽然我试图向我的团队解释这一点，但每个人都站在高级dev & 我被告知要回到绘图板并重新实现我的数据库修复，而不依赖于外键约束。换句话说，我被要求在没有 RDBMS（posgres，如果重要的话）的内置关系管理工具的情况下进行关系管理。

我重申这不是修复错误的正确方法，此时我的老板告诉我讨论占用了太多时间，如果我想辩论正式 FK 约束的优点，我需要以后再做……我打算这样做，但我也觉得我的任务是争论为什么水是湿的。

当我进入这场辩论时，我想用尽可能多的事实来支持外键的使用。我知道实施合理的 FK 约束：

1. 作为防止关系不一致的自动护栏（即，防止“垃圾数据”（这是我目前正在使用的系统的一个明显问题）），
2. 向正在检查数据库模式的人阐明两个相关表之间的高级关系上下文，以及
3. 可以提高数据库查询操作的性能。

......但我想知道在这个主题上是否还有其他我可能遗漏的要点，我应该用这些要点来应对这场辩论。我应该确保向我的老板和同事提出哪些其他好处？（或者真的有范式转变远离 FK 约束，当它发生时我一直把头埋在石头下？）