因此，虽然我们在当前项目中使用外键，但我之前听说过在开发环境中启用外键检查只会在开发人员面前设置障碍 - 代码不应该依赖外键到位
我想知道人们对这个想法的看法 - 在开发时，您是否在开发环境中启用了外键，或者是否将其关闭？
答案 0 :(得分：24)
我总是让它们保持启用状态。您希望确保您的代码不会执行违反FK规则的操作。如果删除它们，则无法阻止代码输入错误数据。此外，我们将使用CodeSmith等工具来帮助我们完成一些自动化工作，如果我们有FK，它可以自动为我们生成查询程序。
总的来说，我坚信开发环境应该与生产环境非常接近。如果你没有它们，很可能会有生产失败的代码，因为它违反了FK约束，并且在测试中它可以正常工作。
答案 1 :(得分：9)
绝对保持启用它们。外键约束的存在实际上在开发中非常有用;不使用约束可以允许惰性开发;此外，它可以让一些严重的问题蔓延到代码中，这可能会在转移到生产环境时造成一些困难。
答案 2 :(得分：6)
我总是在我的环境中启用FK。这样做的原因是如果我编码没有FK的东西可能会打破后来打开它们。
即使打开它们可能会引起一些麻烦，但从长远来看，这是值得的。
答案 3 :(得分：4)
我强烈建议您继续使用它们。它提供了一个安全的网络，以确保您的数据层正常运行。除非您正在使用ETL应用程序，否则您需要关闭数据加载的约束。
答案 4 :(得分：4)
你保持启用它们。如果它们在您的测试和生产环境中启用，那么它们也应该在您的开发环境中，或者您只是将潜在的问题推送到另一个环境，这实际上会花费更长的时间来修复。
答案 5 :(得分：4)
在我看来，在开发环境中使用外键不会成为障碍，但会带来好处。数据完整性是一件好事，外键是强制执行它的好方法。
答案 6 :(得分：2)
这就像说“运行失败的测试”给开发团队带来了困难。约束的全部意义在于确保系统的有效性和正确性。
花时间为开发过程开发所需的支持基础架构，以便于添加和修改数据库。
答案 7 :(得分：1)
外键不应该依赖于代码。我会考虑这个愚蠢的建议。很容易搞砸数据库的参照完整性，开发人员犯了很多错误。与c＃开发人员对类型安全的理解方式相同，任何为数据库开发的人都会喜欢保护参照完整性。
但是，对于批量插入等，可能会更快地关闭FK约束，但只有在启用它们的全面测试之后才会更快。
答案 8 :(得分：1)
我〜总是启用FK，我理解应用逻辑应该强制执行数据约束但不依赖于DB约束本身的论点的前提，除此之外，但我不认为我会成为第一个拥有FK的人在我的应用程序逻辑之前错过了一个级联约束，并且数据库已经为我选择了这个，我想这是非常常见的，并且在开发循环中获得这个，比在生产环境中更容易托盘！
答案 9 :(得分：1)
除了其他帖子中的许多原因之外，在开发中禁用外键存在很大的风险，您编写的代码将无法在生产中运行。例如，假设您在创建订单之前创建了一个订单行。没有外键的情况下运行正常，但启用时会失败。
答案 10 :(得分：1)
我很高兴看到其他答案几乎一致，你应该在开发中保持约束。
我想补充一点，当尝试的数据INSERT / UPDATE / DELETE导致约束违规时，您的代码需要处理异常。在生产中发生这种情况时，您需要使用正确的代码才能正常工作。因此，必须在开发和测试期间启用约束。
答案 11 :(得分：0)
我要说，让我们删除约束。
打倒FK！
并删除所有索引，以及所有其他约束。
开玩笑吧。 ：）当然..尽量让它尽可能接近生产 - 缩小数据大小，请在分发数据之前请先清理数据。
答案 12 :(得分：-2)
没有冒犯，但你们听起来像一群绵羊在喷射什么强力喂给你。对于任何SQL Server问题，答案总是“它取决于。”
外键旨在规范可以将手放入饼干罐中的人。如果您设计了一种有效的方法将饼干分配给他人并防止直接进入饼干罐，您就不需要外键。