Database design 外键是邪恶的？

很抱歉以化名发布，但由于公司限制，为了保护无辜，我不得不匿名发布

我已经做了18年的专业开发人员，虽然我不是DBA，但多年来我一直与他们密切合作，并形成了一种相当不错的感觉，即什么是好的数据库实践，什么不是好的数据库实践。我刚刚加入了一家公司，有两名开发人员负责数据库模式，我发现他们非常反对使用外键约束

据我所知，他们的理由是 （1） 由于涉及到额外的数据设置和 （2） 外键可能会引发错误，因为顺序很重要。他们实际上更喜欢孤立数据，而不是停止应用程序

对我来说，这似乎是一种不好的做法，但他们的立场是坚定不移的。我们已经介绍了外键在数据完整性、查询性能、生成数据库图等方面提供的优势，但这些优势都是徒劳的

---

我在这里没看到什么吗？有什么建议吗

如果您所描述的是开发人员使用外键的一般方法，那么我认为他们是被误导或天真的。当然，外键约束不能或不应该应用于任何给定系统中的某些特定属性，这很可能是有充分理由的。也许这就是表面上的花言巧语背后的真正原因

我的建议。如果您是相关系统的利益相关者，那么不要与开发人员交谈，而是与开发经理或系统所有者交谈。用缺乏引用完整性会产生不利影响或带来未来风险的具体例子来支持您的案例

---

如果您目前没有与RI相关的问题，那么您可能主要关心的是为将来的工作改进政策或开发方法。与数据库经理、DBA或负责标准和信息风险的人员交谈。考虑投资开发一些培训、指导或咨询，以帮助开发团队。

< P>我已经设计数据库系统超过30年了。这是我的看法——你可能不会喜欢它。在设计封闭的系统时，您的参考完整性可能会内置到应用程序的用户界面中。您只能在用户界面要求颜色的位置添加产品实体记录。那为什么有外键呢？我不会在任何人都可以做任何事情的地方打开数据库，因此典型的后端会有数千行前端代码来保护数据的完整性。栓接的外键只会碍事，不会为您提供任何真正的服务。外键不会抛出异常，然后您会捕获该异常并向用户发布消息。没有人，我的意思是没有人这样编码。我们所有的程序员都喜欢冲进来，把所有的酷东西直接放到用户界面上。但正如我所说，我使用的是封闭系统，由开发人员控制索引，另一方面-非常重要。先解决这个问题。外键-只是语法上的松懈。

第（1）点听起来似乎只需稍加努力就可以解决。第（2）点可以通过简单地按顺序插入数据来解决，这通常不难做到。这是一种征求意见，因此，对于这个网站来说，这不是一个合适的问题。你可能想展示它们。FKs可以节省时间和维护成本：当需求发生变化时，你可以在一个地方而不是在每个应用程序中改变约束。FKs提高了查询性能：优化器可以使用FKs重写和优化执行计划。FK是声明性的，而不是过程性的：它们始终应用于所有数据，而不仅仅是在应用程序中生效期间。FKs支持与其他工具和流程、ETL、开发和管理工具、代码生成和许多其他东西的集成。FK不是语法上的绒毛！！我想你可能把外键和索引搞混了。嗨，斯科特。我不是。通常情况下，外键属性是很好的索引候选项，但在我的回答和评论中，我肯定不会这样假设。无论FK列是否被索引，FK约束都是重要且有用的。我很乐意同意不同意。你的评论非常好，我强烈建议任何阅读它们的人都要留心。这就是为什么我投了他们更高的票。但我相信，随着计算机界的智慧和经验法则的变化，外键会变得非常有用，如果你了解外键的用途和作用的话。它们将以最常见的措辞提供强制数据完整性。换句话说，不能将值插入到其他地方不存在的表中，例如，可以说您不需要为每个可能的值都有一个表，但必须在数据库级别谨慎使用，以确保数据如预期的那样具体，否则跳过外键。