Database 什么'；外键怎么了？

我记得有人提到他几乎从未使用过外键（如果我没记错的话）。然而，在我看来，它们对于避免整个数据库中的重复和随后的数据完整性问题非常重要

人们是否有一些确凿的理由来解释原因（以避免按照堆栈溢出原则进行讨论）

---

编辑：

没有好的理由不使用它们。。。除非孤立行对您来说不是什么大问题。

外键对于任何关系数据库模型都是必不可少的。

我一直认为不使用它们是懒惰的。我被教导应该一直这样做。但是，我没有听乔尔的讨论。他可能有一个很好的理由，我不知道。

他们会让删除记录变得更麻烦-如果在其他表中存在外键会违反该约束的记录，则不能删除“主”记录。可以使用触发器进行级联删除

如果不明智地选择了主键，那么更改该值将变得更加复杂。例如，如果我将我的“customers”表的PK作为该人员的姓名，并将该键设置为“orders”表中的FK，如果该客户想要更改其姓名，则这是一个巨大的痛苦……但这只是劣质的数据库设计

---

我相信使用fireign键的优点大于任何假定的缺点。

我听到的论点是前端应该有这些业务规则。外键“增加了不必要的开销”“当你不应该允许任何一开始就破坏你的限制的插入时。我同意这一点吗？不，但这是我一直听到的

---

编辑：我猜他指的是外键约束，而不是外键作为一个概念。

我同意前面的答案，因为它们有助于保持数据一致性。然而，几周前有一次会议讨论了标准化和一致性数据的利弊

---

简而言之，当处理大量数据时，非规范化数据库可以更快；根据应用程序的不同，您可能不关心精确的一致性，但这会迫使您在处理数据时更加小心，因为数据库不会这样。

有一个很好的理由不使用它们：如果您不了解它们的作用或如何使用它们。

在错误的情况下，外键约束可能导致事故的瀑布式复制。如果有人删除了错误的记录，撤销它可能会成为一项艰巨的任务

---

同样，相反，当您需要删除某些内容时，如果设计不当，约束可能会导致各种各样的锁阻止您

验证外键约束需要一些CPU时间，因此有些人省略外键以获得额外性能。

Clearify数据库是没有主键或外键的商业数据库的一个示例

有趣的是，技术文档详细解释了表是如何关联的，使用哪些列连接它们等等

换句话说，他们可以用显式声明（DRI）加入表，但他们选择不加入

因此，Clarify数据库充满了不一致性，表现不佳

但我认为这使开发人员的工作更容易，不必编写代码来处理引用完整性，例如在删除、添加之前检查相关行

---

我认为，这是关系数据库中没有外键约束的主要好处。它使开发变得更容易，至少从魔鬼可能关心的角度来看是这样

@imphasing-这正是导致维护噩梦的心态

---

为什么，为什么你会忽视声明性引用完整性，在声明性引用完整性中，数据至少可以保证一致性，而支持所谓的“软件强制执行”，这充其量只是一种薄弱的预防措施。

我肯定有很多应用程序可以避免这种情况，但这不是最好的主意。您不能总是依靠应用程序来正确管理数据库，坦率地说，管理数据库对应用程序来说应该不是很重要

---

如果您使用的是关系数据库，那么似乎应该在其中定义一些关系。不幸的是，这种态度（您不需要外键）似乎受到了许多应用程序开发人员的欢迎，他们不愿意为数据完整性等愚蠢的事情而烦恼（但需要这样做，因为他们的公司没有专门的数据库开发人员）。通常在由这些类型组合而成的数据库中，只有主键是幸运的；）

我也听到过这种说法——有些人忘记在外键上加索引，然后抱怨某些操作太慢（因为约束检查可以利用任何索引）。总而言之：没有理由不使用外键。所有现代数据库都支持级联删除，所以…

我总是使用它们，但我为金融系统创建数据库。数据库是应用程序的关键部分。如果金融数据库中的数据不完全准确，那么您在代码/前端设计上投入了多少精力就无关紧要了。你只是在浪费时间

还有一个事实是，多个系统通常需要直接与数据库接口——从只读取数据的其他系统（Crystal Reports）到插入数据的系统（不一定使用我设计的API；它可能是由一个愚蠢的经理编写的，他刚刚发现了VBScript，并且拥有SQL框的SA密码）。如果数据库不像可能的那样防白痴，那么再见数据库

如果你的数据很重要，