级联时不需要外键 [英] Foreign keys when cascades aren't needed

问题描述

如果我不需要在逻辑上使用 cascade / restrict 和类似的约束一个外键，我有什么理由显式声明它为外键，而不是美学？ p>

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

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

• 我不会编辑或删除这些值，所以我不在调用 INSERT 之前，需要执行 cascade 和类似的检查。我会检查目标键是否存在，所以我不需要 restrict 检查

据我所知，如果数据库变坏了，这种约束将确保该关系依然有效，这是一件好事。但是，我想知道是否有任何其他原因使用这个功能在我的情况。我错过了什么？

解决方案

您必须这样做。如果它会触及写入性能 - 这是一个像素问题。

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

所以答案是 - 是的，这不仅仅是音乐。

If I don't need to use cascade/restrict and similar constraints in a field which would logically be a foreign key, do I have any reason to explicitly declare it as a foreign key, other than aesthetics?

Wouldn't it actually decrease performance, since it has to test for integrity?

edit: to clarify, I don't need it since:

• I won't edit nor delete those values anyway, so I don't need to do cascade and similar checks
• Before calling INSERT, I'll check anyway if the target key exists, so I don't need restrict checks either

I understand that this kind of constraint will ensure that that relation will be still valid if the database becomes somehow corrupted, and that is a good thing. However, I'm wondering if there is any other reason to use this function in my case. Am I missing something?

解决方案

You must to do it. If it will touch performance in write -- it's a "pixel" problem.

Main performance problems are in read -- FKs could help query optimizer to select best plan and etc. Even if you DBMS(-s) (if you provide cross-DBMS solution) will gain from it now -- it can happen later.

So answer is -- yes, it's not only aestetics.

这篇关于级联时不需要外键的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！