以编程方式强制执行外键的优点和缺点比数据库中的优点和缺点

仅仅通过让数据库强制执行外键，它在开发方面造成了很多麻烦。特别是在单元测试期间，由于外键限制，我不能删除表，我需要按照这样的顺序创建表，以免外键约束警告被触发。实际上，我并没有看到让数据库执行外键约束的太多问题。如果应用程序设计合理，除选择查询外，不应该进行任何手动数据库操作。我只想确保我不会因为在数据库中没有外键约束而将自己陷入漏洞，而仅仅是由于应用程序的责任。我错过了什么？以编程方式强制执行外键的优点和缺点比数据库中的优点和缺点

P.S.如果底层域对象的结构已被修改，我真正的单元测试（不是那些使用模拟的）将会删除现有的表。

来源

2010-04-01 Jeff

以我的经验，如果你没有在数据库中执行外键，然后最终（假设数据库是比较大的，并大量使用），您将结束与孤立的记录。这可能发生在许多方面，但似乎总是发生。

如果指数正常，不应该有任何的性能优势外键。

所以现在的问题是，它的潜在危害/麻烦/支持成本/金融在你的数据库中的孤立记录的成本超过了开发和测试的麻烦？

以我的经验，对于业务应用程序，我总是使用外键。它应该只是一次性安装成本，让您的构建脚本正常工作，并且数据的稳定性将超过应用程序的整个生命周期。

来源

2010-04-01 01:03:54

在数据库中执行规则的关键在于它是声明性的 - 例如，你不必编写大量的代码来处理它。

就你的单元测试而言，只需按正确的顺序删除表。你只需编写一个函数就可以做到这一点。

来源

2010-04-01 01:00:36 AngryHacker

我在考虑添加一个答案，但你说什么需要说，所以得到你的选票。如果开发人员缺乏编写设置和重置脚本以准备测试前提条件的技术技能，则他们不应直接在数据库上运行。在这种情况下，DBA应该准备这样的脚本。但是抛开参照完整性，因为开发人员想要懒惰？没门！ – 2015-09-23 00:07:48

这里就中越在前面的问题上一个很好的讨论：What's wrong with foreign keys?。 [编辑]：这个论点是，如果任何一个缺点适用，使非强制外键得到一些专家。

来源

2010-04-01 01:05:21 Turnkey

这似乎是你可以依靠你的应用程序遵循隐含的规则，但除非你强制他们最后总会有人犯错误。
或者也许5年后，有人会对旧的记录进行整理，而这些记录“不再需要”，并且没有意识到其他表中仍然有数据参照。然后，几天/几周后，您或您的继任者将获得尝试修复数据库所遇到的混乱的有趣工作。 :-)

来源

2010-04-01 01:12:43 hamishmcn

不应该在应用程序级别进行归档吗？ – Jeff 2010-04-01 01:20:35

我为一家拥有大量客户记录和相关数据的公司工作了8年，尽管最好的意图是各种各样的事情出错了。人们在对数据库有完整的了解的情况下做出改变。任何帮助他们避免犯错的帮助最终都会带来回报 – hamishmcn 2010-04-01 20:02:58

您在开发中的问题不应该驱动数据库设计。不断重建数据库是一个开发人员用例，而不是客户用例。

此外，数据库约束有助于超越您的应用程序。你永远不知道你的客户可能会尝试做什么。不要这样做，但你需要一些。

来源

2010-04-01 01:14:47

这取决于您坚持的测试理论。根据Roy Osherove在他的单元测试书中所说，写得好的测试应该被认为是代码的合法用户。 – 2011-08-10 14:31:52

你说得很好。 – 2011-08-17 13:58:23

@Kazark，但他们的需求不会取代数据用户的需求。以开发人员为中心的数据库设计是一场灾难。当开发缓解应该胜过数据完整性时，没有任何条件。 – HLGEM 2013-04-08 19:08:42

如果该应用程序已被正确设计的，不应该有任何手工数据库操作等比选择查询

什么？你喝什么样的koolaid？大多数数据库应用程序都是用来处理数据库中的数据，而不仅仅是查看它。一般而言，应用程序的全部用途是添加新订单或创建新客户记录或记录客户服务电话等。

外键用于数据完整性。数据完整性对于能够以任何可靠性使用数据至关重要。没有数据完整性的数据库是无用的，会导致公司损失资金。这胜过以自我为中心的观点，认为FKs不是必需的，因为它们会让你的开发变得更加复杂。这些数据远比您在运行测试时的便利性更重要（可以将这些数据写入FK中）。

来源

2010-04-01 17:13:31 HLGEM

是啊koolaid是什么？什么样的应用程序具有专有的只读数据库 – 2013-04-08 18:31:51

以编程方式强制执行外键的优点和缺点比数据库中的优点和缺点

回答

相关问题