database-design - Sql - 间接外键

Question

我有一些关于数据库设计的问题。

这个有名字吗？

是好习惯吗？

任何性能考虑？

我有一个用于存储关系的通用表结构。

最近我重构了一些东西以使用这种通用结构而不是直接的 Fk 列，但现在我不确定这是否真的是最好的主意。

原始架构:

+--------------------+ +--------------------+ +------ ----------------+
|预订 | |注意 | |元母 |
|-------------------| |---------------------| |----------------------|
|身份证 | |身份证 | |身份证 |
| NoteId | | MetaParentId:(空) | |元表 ID |
| +-------+ +----+ KeyValue |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+--------------------+ +--------------------+ +------ ----------------+

新架构

+--------------------+ +--------------------+ +------ ----------------+
|预订 | |注意 | |元母 |
|-------------------| |---------------------| |----------------------|
|身份证 | |身份证 | |身份证 |
| | | MetaParentId:(空) | |元表 ID |
| + + +----+ 键值 |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+--------------------+ +--------------------+ +------ ----------------+

所以基本上不是在 Book 和 Note 之间有直接的 Fk 关系，而是通过使用 MetaTableId/KeyValue 列的 MetaParent 表建立间接关系。

目前 MetaParent 表有大约 50 万条记录，并且运行正常。但是我们每天晚上都会在其上重建索引。

我担心的是现在 Book 和 Note 之间的关系并不明显。您必须知道一个存在并使用 MetaParent 表。

还有性能，我不确定在什么时候我们会遇到针对 MetaTableId/KeyValue 运行太慢的连接问题。似乎您向该表添加的越多，查询速度就会越慢。

Answer 1

您应该始终使用“正常”的 FOREIGN KEY 来强制执行参照完整性。

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

它们已经在 DBMS 中实现了。

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

它们不能被绕过(除非明确禁用或丢弃)。

他们是对的。

他们很快。

它们支持级联引用操作(例如 ON DELETE CASCADE)。

DBMS 知道数据是相关的，允许它在 some cases 中找到更好的查询计划。

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

以下是在应用程序代码中实现参照完整性的相应缺点:

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

这是必要的，可能“深埋”在您的应用程序源代码中，并且更难维护。

存在错误的单个客户端应用程序可能会破坏参照完整性(并损坏数据)。

您可能在应用程序代码中错误地实现了它们。它从一开始看起来很简单，但在并发环境中， it is easy to introduce race conditions 。

即使您正确地实现了它们，您也可能使用了某种形式的锁定来避免竞争条件，这可能比 DBMS 中内置的专门优化的 FK 更慢/可扩展性更差。

你必须自己实现级联。

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

你可能需要在你选择的 ORM 工具中做更多的手工工作。

Is there a name for this?

从来没听说过。我听说使用了一个术语“通用 FK”，但这可能并不普遍。

Is it good practice?

否(见上文)。

Any performance considerations?

是(见上文)。