SQL-间接外键

Question

我对数据库设计有一些疑问。有这个名字吗？这是好习惯吗？有性能方面的考虑吗？我有一个用于存储关系的通用表结构。最近，我重构了一些东西来使用这种通用结构，而不是直接使用Fk列，但是现在我不确定这是否真的是最好的主意。原始架构： + ------------------ + + --------------------- + + ------ ---------------- + | 书本 | 注意事项 | MetaParent | | ------------------ | | --------------------- | | ---------------------- | | ID | | ID | | ID | | NoteId | | MetaParentId :(空）| | MetaTableId | | + ------- + + ---- + KeyValue | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + ------------------ + + --------------------- + + ------ ---------------- +新架构 + ------------------ + + --------------------- + + ------ ---------------- + | 书本 | 注意事项 | MetaParent | | ------------------ | | --------------------- | | ---------------------- | | ID | | ID | | ID | | | | MetaParentId :(空）| | MetaTableId | | + + + ---- + KeyValue | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + ------------------ + + --------------------- + + ------ ---------------- +因此，基本上，与在Book和Note之间没有直接的Fk关系相比，我们通过使用MetaTableId / KeyValue列的MetaParent表具有间接关系。当前，MetaParent表具有约50万条记录，并且一切运行正常。但是我们每天晚上都会重建索引。我担心的是，现在Book和Note之间的关系并不明显。您必须知道一个存在并使用MetaParent表。在性能方面，我不确定在什么时候遇到针对MetaTableId / KeyValue的连接运行太慢的问题。似乎您添加到该表中的越多，查询速度就越慢。

Answer 1

您应该始终通过使用“常规” FOREIGN KEY来强制实现引用完整性。

简而言之，FOREIGN KEY具有以下优点：

它们已经在DBMS中实现。

它们是声明性的，自我记录的和“显而易见的”。

它们不能被绕过（除非被明确禁用或删除）。

他们是正确的。

他们很快。

它们支持级联引用动作（例如ON DELETE CASCADE）。

DBMS知道数据是相关的，因此在某些情况下可以找到更好的查询计划。

如果使用的是ORM工具，则它可以自动在对象之间生成引用。

以下是在应用程序代码中强制执行引用完整性的相应缺点：

您正在复制已经完成的工作。

它势在必行，可能会“深埋”在您的应用程序源代码中，并且很难维护。

具有错误的单个客户端应用程序可能会破坏参照完整性（并破坏数据）。

您可能会在应用程序代码中错误地实现它们。从一开始看起来很简单，但是在并发环境中，很容易引入竞争条件。

即使正确实现了它们，您也可能会使用某种形式的锁定来避免争用情况，这比DBMS中内置的经过特别优化的FK可能更慢/可扩展性更小。

您必须自己实现级联。

DBMS不知道数据是否相关，这可能会产生次优的查询计划。

您可能需要在所选的ORM工具中进行更多的手动工作。

有这个名字吗？

从来没听说过。我听说使用了“通用FK”一词，但这可能不是通用的。

这是好习惯吗？

否（请参见上文）。

有性能方面的考虑吗？

是的（见上文）。