定义外键有什么好处

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

在数据库结构仍然不稳定时禁用FK可能会有所帮助，但是当架构更加稳定时，它们是很好的保障。

Answer 3

外键保证外表中存在匹配记录。想象一个名为Books的表，它在名为Authors的表上具有FK约束。每本书都保证有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记录与Person相关联，那么PhoneNumber记录在因任何原因被删除时会发生什么？ 它们仍然存在于数据库中，但它们所涉及的Person的ID将不再存在于相关的Person表中，并且您有孤立的记录。

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

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

通过创建确保任何PhoneNumber与现有PhoneNumber相关的外键，您既可以防止破坏此关系，也可以为预期的数据结构添加“线索”。

Answer 5

主要好处是数据完整性和级联删除。您还可以在定义这些字段并将这些字段正确编入索引后获得性能提升。例如，您将无法创建不属于某个联系人的电话号码，或者当您删除该联系人时，您可以将其设置为自动删除所有电话号码。是的，你可以在你的UI或中间层建立这些连接，但如果有人使用SQL而不是你的UI直接针对服务器运行更新，你仍然会遇到孤儿。 “麻烦”部分只是强迫您在进行批量更改之前考虑这些连接。 FK多次保存我的培根。