Are foreign keys really necessary in a database design?据我所知，外键(FK)用于帮助程序员以正确的方式操作数据。 假设程序员实际上已经以正确的方式执行此操作，那么我们真的需要外键的概念吗？ 外键还有其他用途吗？ 我在这里错过了什么吗？ 外键有助于在数据级别强制引用完整性。它们还可以提高性能，因为它们通常默认为索引。
外键还可以帮助程序员使用 我无法想象没有外键设计数据库。没有它们，最终你一定会犯错误并破坏数据的完整性。 严格来说，它们不是必需的，但是它们的好处是巨大的。 我很确定FogBugz在数据库中没有外键约束。我很想知道Fog Creek Software团队如何构建他们的代码以保证他们永远不会引入不一致。 没有FK约束的数据库模式就像没有安全带的驾驶一样。 有一天，你会后悔的。不要在设计基础和数据完整性上花费那么多的额外时间，这是确保后期头痛的可靠方法。 你会接受你的应用程序中那些草率的代码吗？直接访问成员对象并直接修改数据结构。 为什么你认为这在现代语言中变得困难甚至是不可接受的？ 是。 就个人而言，我赞成外键，因为它正式化了表之间的关系。我意识到你的问题预先假定程序员没有引入会违反参照完整性的数据，但是我已经看到了太多违反数据参照完整性的情况，尽管有最好的意图！ 前外键约束(也称为声明性引用完整性或DRI)花费了大量时间来使用触发器实现这些关系。我们可以通过声明性约束来形式化关系这一事实非常强大。 @John - 其他数据库可能会自动为外键创建索引，但SQL Server不会。在SQL Server中，外键关系仅是约束。您必须单独在外键上定义索引(这可能是有益的。) 编辑：我想补充一点，IMO，使用外键支持ON DELETE或ON UPDATE CASCADE不一定是件好事。在实践中，我发现应该根据数据的关系仔细考虑删除级联 - 例如你有一个自然的亲子，这可能是好的或相关的表是一组查找值。使用级联更新意味着您允许修改一个表的主键。在这种情况下，我有一个普遍的哲学分歧，因为表的主键不应该改变。键应该是固有的。
在我看来，做出这样的假设是一个非常糟糕的主意;一般来说，软件是非常错误的。 这就是重点，真的。开发人员无法把事情弄清楚，因此确保数据库不能填充不良数据是一件好事。 虽然在理想的世界中，自然连接将使用关系(即FK约束)而不是匹配列名。这将使FK更加有用。 如果没有外键，您如何判断不同表中的两条记录是否相关？ 我认为你所指的是引用完整性，其中不允许在没有现有父记录等的情况下创建子记录。这些通常被称为外键约束 - 但不要与外键存在混淆。第一名。 我想你在谈论数据库强制执行的外键约束。您可能已经在使用外键，您只是没有告诉数据库它。
从理论上讲，没有。但是，从来没有一个没有错误的软件。 应用程序代码中的错误通常不那么危险 - 您确定错误并修复它，然后应用程序再次顺利运行。但如果一个错误允许破解数据进入数据库，那么你就会陷入困境！从数据库中的损坏数据中恢复非常困难。 考虑一下FogBugz中的一个微妙的错误是否允许在数据库中写入损坏的外键。修复错误可能很容易，并在修补程序版本中快速将修复程序推送给客户。但是，如何修复数十个数据库中的损坏数据呢？正确的代码现在可能会突然中断，因为关于外键完整性的假设不再存在。 在Web应用程序中，您通常只有一个程序与数据库通信，因此只有一个地方可以破坏数据。在企业应用程序中，可能有几个独立的应用程序与同一个数据库通信(更不用说直接使用数据库shell的人)。没有办法确保所有应用程序遵循相同的假设，没有错误，永远和永远。 如果在数据库中对约束进行编码，则错误可能发生的最坏情况是向用户显示关于某些不满足的SQL约束的丑陋错误消息。这更容易让数据陷入企业数据库，反过来又会破坏所有应用程序或导致各种错误或误导性输出。 哦，外键约束也提高了性能，因为它们默认是索引的。我想不出任何不使用外键约束的理由。 没有外键有没有好处？除非您使用的是蹩脚的数据库，否则FK并不难设置。那你为什么要有避免它们的政策呢？拥有一个命名约定是一回事，即一个列引用另一个列，知道数据库实际上是为你验证这种关系是另一回事。 FK非常重要，应该始终存在于您的架构中，除非您是eBay。 我认为在某些时候某些事情必须负责确保有效的关系。 例如，Ruby on Rails不使用外键，但它会验证所有关系本身。如果您只从Ruby on Rails应用程序访问您的数据库，这很好。 但是，如果您有其他客户端正在写入数据库，那么没有外键，他们需要实现自己的验证。然后，您有两个验证代码的副本，这些副本很可能是不同的，任何程序员都应该能够告诉它是一个主要的罪。 此时，外键确实是必要的，因为它们允许您将责任再次移动到单个点。
当程序员不能这样做时，FK允许DBA保护数据完整性免受用户的笨拙，有时可以防止程序员的笨手笨脚。
程序员是凡人和易犯错误的。 FK是声明性的，这使得它们更难搞砸。
虽然这不是创建它们的原因，但FK为图表工具和查询构建器提供了强有力的可靠提示。这将传递给最终用户，他们迫切需要强大可靠的提示。 外键允许之前没有看过您的数据库的人确定表之间的关系。 现在一切都很好，但想想当你的程序员离开而其他人必须接管时会发生什么。 外键将允许他们理解数据库结构，而无需拖拽数千行代码。 它们并非严格必要，因为安全带不是绝对必要的。但它们确实可以帮助你避免做一些弄乱数据库的愚蠢行为。 调试FK约束错误比重建破坏应用程序的删除要好得多。 它们很重要，因为您的应用程序不是数据库中数据操作的唯一方式。您的应用程序可以按照自己的意愿诚实地处理引用完整性，但只需要一个具有正确权限的bozo，并在数据库级别发出插入，删除或更新命令，并绕过所有应用程序引用完整性实施。将FK约束放在数据库级别意味着，除非在发出命令之前选择禁用FK约束，否则FK约束将导致错误的插入/更新/删除语句失败并引用参照完整性。 我在成本/收益方面考虑它......在MySQL中，添加约束是DDL的一个额外线。这只是一些关键词和几秒钟的思考。这是我认为的唯一"成本"...... 工具喜欢外键。外键可防止可能不会影响业务逻辑或功能的错误数据(即孤立行)，从而不会被注意到并构建。它还可以防止不熟悉架构的开发人员实现整个工作块，而不会发现他们错过了关系。也许在您当前应用程序的范围内一切都很好，但是如果您错过了某些东西，并且有一天会添加一些意想不到的东西(想想花哨的报告)，那么您可能需要手动清理自开始以来一直在积累的错误数据。没有数据库强制检查的模式。 当你把东西放在一起时，用很少的时间来编写你脑子里已经存在的东西可能会让你或其他人在未来几个月或几年内挽救一大堆悲伤。 问题：
它有点装。插入注释，缩进或变量命名代替"外键"......如果你已经完全理解了有问题的东西，那对你来说是"没用"。
熵减少。减少数据库中出现混乱情况的可能性。 例如，当我们做出一个假设时：每个订单都有一个客户，假设应该由某个东西强制执行。在数据库中"某事物"是外键。 我认为这值得在开发速度上进行权衡。当然，你可以更快地编写代码，这可能是有些人不使用它们的原因。就个人而言，我已经用NHibernate和一些外键约束来杀死了几个小时，当我执行某些操作时它会生气。但是，我知道问题是什么，所以它不是一个问题。我正在使用普通工具，有资源可以帮助我解决这个问题，甚至可能有人帮忙！ 另一种方法是允许一个bug进入系统(并给予足够的时间，它会)，其中没有设置外键并且你的数据变得不一致。然后，你得到一个不寻常的错误报告，调查和"OH"。数据库搞砸了。现在要修复需要多长时间？ 我们目前不使用外键。在大多数情况下，我们不会后悔。 也就是说 - 由于类似的原因，我们很可能在不久的将来开始更多地使用它们，原因有两个： 图表。如果正确使用外键关系，则生成数据库图表要容易得多。 工具支持。使用Visual Studio 2008构建数据模型要容易得多，如果有适当的外键关系，可以用于LINQtoSQL。 所以我想我的观点是，我们发现如果我们做了大量的手工SQL工作(构造查询，运行查询，blahblahblah)，外键不一定是必不可少的。但是，一旦开始使用工具，它们就会变得更有用。 您可以将外键视为约束，
在我工作的项目(业务应用程序和社交网站)中声明的外键从未明确(FOREIGN KEY REFERENCES表(列))。 但总有一种命名列的常规是外键。 就像数据库规范化一样 - 你必须知道你在做什么以及它的后果是什么(主要是性能)。 我知道外键的优点(数据完整性，外键列的索引，知道数据库模式的工具)，但我也害怕使用外键作为一般规则。 此外，各种数据库引擎可以以不同的方式提供外键，这可能在迁移期间导致细微的错误。 使用ON DELETE CASCADE删除已删除客户端的所有订单和发票是一个很好看但设计错误的数据库模式的完美示例。 外键约束(以及一般的约束)最好的事情是在编写查询时可以依赖它们。如果您不能依赖持有"true"的数据模型，那么很多查询会变得复杂得多。 在代码中，我们通常只会在某处抛出异常 - 但在SQL中，我们通常只会得到"错误"的答案。 从理论上讲，SQLServer可以使用约束作为查询计划的一部分 - 但除了检查分区约束之外，我不能说我曾经亲眼目睹过。 是。 ON DELETE [RESTRICT | CASCADE]使开发人员不会搁置数据，保持数据清洁。我最近加入了一个Rails开发团队，他们没有关注外键等数据库约束。 幸运的是，我发现了这些：http：//www.redhillonrails.org/foreign_key_associations.html - Ruby on Rails插件上的RedHill使用约定优于配置样式生成外键。使用product_id进行迁移将为products表中的id创建外键。 查看RedHill上的其他优秀插件，包括事务中包含的迁移。 |
