不需要级联时的外键答案

【问题标题】：Foreign keys when cascades aren't needed不需要级联时的外键
【发布时间】：2013-03-25 13:47:54
【问题描述】：

如果我不需要在逻辑上为foreign key 的字段中使用cascade/restrict 和类似约束，我是否有任何理由将其明确声明为foreign key，除了审美？

它实际上不会降低性能吗，因为它必须测试完整性？

编辑：澄清一下，我不需要它，因为：

我知道，如果数据库以某种方式损坏，这种约束将确保该关系仍然有效，这是一件好事。但是，我想知道在我的情况下是否还有其他理由使用此功能。我错过了什么吗？

【问题讨论】：

对我来说，性能下降对于参照完整性来说只是很小的代价。
@DanBracuk 当然，我想我不清楚，我会编辑。
您可以将其视为某种礼仪或某种良好的形式。每个人都喜欢带有 cmets 的代码（尤其是当代码很复杂的时候），而不喜欢没有 cmets 的代码。也可以将它们视为某种附加文档。
gaRex 是的，这个问题是他们是否不止于此，您和@Kurrija 的回答都很好:)

【解决方案1】：

this quesiton 的答案实际上可能也适用于您的问题。

如果表中的列引用其他表中的行，则应始终使用外键，因为即使您认为“不需要”这些检查提供的功能，它仍然有助于保证数据完整性以防您忘记检查自己的代码。

在大多数情况下，外键检查的性能影响可以忽略不计（参见上面的链接），因为关系数据库使用非常优化的算法来执行它们（毕竟，它们是一个关键特性，因为它们实际上定义了实体之间的关系） .

FK 的另一个主要优点是它们还可以帮助其他人了解您的数据库的布局。

编辑： 由于上面链接的问题是指 SQL-Server，这里有一个与 MySQL 非常相似的回复：Does introducing foreign keys to MySQL reduce performance

【讨论】：

您引用的问题适用于 SQL Server。
@PolishPrince 抱歉，也为 MySQL 添加了一个链接，但是在回答 SQL Server 问题时给出的使用 FK 的许多原因几乎适用于所有关系 DBMS
我从许多不同的供应商和客户那里获得数据，如果他们没有正式设置 FK，我还从来没有见过有好的数据。数据完整性是数据库设计的首要任务。没有它，您最终会产生垃圾，并且您的数据将变得不可靠。

【解决方案2】：

你必须这样做。如果它会触及写入性能——这是一个“像素”问题。

主要的性能问题正在阅读中——FK 可以帮助查询优化器选择最佳计划等。即使您的 DBMS(-s)（如果您提供跨 DBMS 解决方案）现在会从中受益——它也可能发生稍后。

所以答案是——是的，不仅仅是美学。

【讨论】：