定义外键有什么好处

Question

使用处理关系的MVC框架时定义外键有什么好处？

我正在使用一个关系数据库,其框架允许模型定义与关系.因为外键是通过模型定义的,所以外键似乎是多余的.在开发中管理应用程序的数据库时,编辑/删除使用外键的表是一件麻烦事.

通过完全放弃使用外键,使用外键是否有任何优势？

Answer 1

带有约束的外键(在某些数据库引擎中)可以在低级别(数据库级别)上提供数据完整性.这意味着您无法在物理上创建不满足关系的记录.这只是一种更安全的方式.

Answer 2

它为您提供在数据库级别强制执行的数据完整性.这有助于防止可能导致无效数据的应用程序逻辑中的错误.

如果直接在SQL中绕过应用程序逻辑进行任何数据操作,它还可以防止破坏这些约束的坏数据.

另一个好处是它允许工具使用从模式本身推断出的关系自动生成数据库图表.现在理论上所有的图表都应该在创建数据库之前完成,但是随着数据库的发展超出了它的初始化身,这些图表通常不会保持最新,并且从现有数据库生成图表的能力对于审查,以及向加入项目的新开发人员解释结构.

在数据库结构仍然不稳定的情况下禁用FK可能会有所帮助,但是当架构更稳定时,它们是很好的保护措施.

Answer 3

外键保证外表中存在匹配记录.想象一下一个名为的表Books,它在一个名为的表上有一个FK约束Authors.每本书都保证有Author.

现在,您可以执行以下查询:

SELECT B.Title, A.Name FROM Books B
INNER JOIN Authors A ON B.AuthorId = A.AuthorId;

如果没有FK约束,缺少的Author行将导致整Book行被删除,从而导致数据集中的书籍丢失.

此外,使用FK约束,尝试删除至少由一本书引用的作者将导致错误,而不是破坏您的数据库.

Answer 4

虽然在操作开发/测试数据时它们可能会很痛苦,但它们在生产中为我节省了很多麻烦.

将它们视为维护数据完整性的一种方式,尤其是作为防止孤立记录的安全措施.

例如,如果您有一个数据库将许多PhoneNumber记录与a相关联Person,那么PhoneNumber当Person记录因任何原因被删除时,记录会发生什么？它们仍将存在于数据库中,但Person它们所涉及的ID 将不再存在于相关Person表中,并且您具有孤立记录.

是的,您可以编写一个触发器来删除PhoneNumber每当删除时Person,但如果您不小心删除Person并需要回滚,这可能会变得混乱.

是的,您可能还记得PhoneNumber手动删除记录,但是您在9个月后编写的其他开发人员或方法呢？

通过创建确保任何PhoneNumber与现有关系相关的外键Person,您既可以防止破坏这种关系,也可以为预期的数据结构添加"线索".