时间戳

首页 > 解决方案 > 使用同一列作为两个不同表的外键的优点/缺点？

database - 使用同一列作为两个不同表的外键的优点/缺点？

问题描述

想象一下，您有一个平台，用户可以在其中撰写文章。这些文章根据它们的类型分为两个不同的表：您有 type1 和 type2 文章。对于每种类型的文章，您需要不同的列，并且您需要处理它们略有不同，因此为什么要将它们分成两个表。

尽管这两种类型的文章保存在两个单独的表中，但您希望将它们的主键用作表中同一列的外键，文章的类型并不重要，例如跟踪他们的视图，收藏夹，喜欢/不喜欢，标志，无论你有什么。它可能看起来像这样：

id | type | articleId | whatever
===+======+===========+=========
1  | 1    | 1         | ...     
---+------+-----------+---------
2  | 2    | 1         | ...     
---+------+-----------+---------
3  | 1    | 2         | ...     
---+------+-----------+---------

“type”基本上定义了您应该将“articleId”加入哪个表，这意味着type和articleId组合始终是唯一的。

这有什么好处和坏处？这种表会随着时间的推移快速增长，我担心如果您必须基于另一列连接表，这可能会大大降低查询速度。我是否应该为每种文章类型保留单独的表格以显示收藏夹、视图等？

标签： database

解决方案

有条件的加入目标对我来说当然不理想。在这种情况下，我不确定 RDBMS 甚至可以保持完整性。相反，考虑一种方法，将标识符集中在一种超级表中，然后让所有其他表引用它。

例如，考虑一个文章表：

Articles
--------
ID (PK, IDENTITY)
(any other info common to all articles)

然后，您的不同“类型”对此具有 FK：

Type1Articles
--------
ID (PK, FK to Articles)
(info about type 1 articles)

Type2Articles
--------
ID (PK, FK to Articles)
(info about type 2 articles)

扩展文章信息的其他表可以引用相同的超级表。例如，如果您有一个多对多表将任何类型的文章链接到标签：

ArticleTags
--------
ArticleID (PK, FK to Articles)
TagID (PK, FK to Tags)

或者，也许你有一个多对多的表，它只适用于给定类型的文章。您仍然可以引用该表，并且约束将全面适用：

Type1ArticleWidgets
--------
ArticleID (PK, FK to Type1Articles)
WidgetID (PK, FK to Widgets)

基本上，从通用描述一个的信息开始Article（即使唯一通用的信息只是密钥标识符），然后将其他子表挂在该表之外。

推荐阅读