以编程方式强制执行外键相对于数据库的优缺点：

Question

15 浏览2023年2月7日

匿名的 2023年2月8日

0 Comments

让数据库强制执行外键约束对于开发造成了很多麻烦。特别是在单元测试期间，由于外键约束，我无法删除表格，我需要按照一定的顺序创建表格，以避免触发外键约束警告。实际上，我不太明白让数据库执行外键约束的意义。如果应用程序被正确设计，除了选择查询之外不应该有任何手动数据库操作。我只是想确保我没有因为在数据库中没有外键约束，而完全依赖应用程序的责任而使自己陷入困境。我有什么遗漏的吗？附注：如果底层领域对象的结构已被修改，我的真实单元测试（不是使用模拟的测试）将删除现有的表格。

0

3 答案

匿名的 · Answer 1 · 2023-02-25T23:57:27+00:00

在开发过程中，你的问题不应该驱动数据库设计。不断重建数据库是开发人员的使用案例，而不是客户的使用案例。

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

这取决于你坚持的测试理论。根据罗伊·奥舍罗夫在他的单元测试书中的观点，良好编写的测试应该被视为代码的合法用户。

然而，他们的需求不能超越数据的用户。以开发人员为中心的数据库设计是一场灾难的开始。没有条件可以使开发的便利胜过数据的完整性。

问题的出现原因是：开发人员过度关注开发的便利性，而忽视了数据的完整性和用户的需求。

解决方法是：不让开发问题驱动数据库设计，不断重建数据库是开发人员的使用案例，而不是客户的使用案例。同时，需要使用数据库约束来帮助超越应用程序的使用。测试应该被视为代码的合法用户。开发人员不能以自己为中心进行数据库设计，而应该考虑数据的完整性和用户的需求。

匿名的 · Answer 2 · 2023-06-22T23:43:47+00:00

在我个人的经验中，如果在数据库中不强制执行外键，那么最终（假设数据库相对较大且使用频繁）会出现孤立记录。这种情况可能以多种方式发生，但它总是会发生。

如果正确建立索引，那么外键不会带来任何性能优势。

因此，问题是，数据库中出现孤立记录的潜在损害/麻烦/支持成本/财务成本是否超过了开发和测试的麻烦？

根据我的经验，在业务应用中我总是使用外键。正确设置构建脚本只需要一次性成本，并且数据的稳定性将在应用程序的整个生命周期内超过这个成本。

匿名的 · Answer 3 · 2023-07-09T11:31:13+00:00

在数据库中强制执行外键的优点是它的声明性。这意味着你不需要编写大量的代码来处理它。至于单元测试，只需按正确的顺序删除表即可。你只需要编写一个函数来正确执行这个操作一次。

如果开发人员缺乏编写设置和重置脚本以准备测试前提条件的技术能力，那么他们就不应该直接操作数据库。在这种情况下，应该由数据库管理员来准备这些脚本。但是放弃引用完整性只是因为开发人员想偷懒？绝对不行！

问题的原因：开发人员缺乏技术能力来编写设置和重置脚本以准备测试前提条件。

解决方法：由数据库管理员准备测试前提条件的脚本。