关系表应该是什么样子 - 需要确认我的技术

Question

假设我有 3 个模型：

• 用户
• 页面
• 评论

我根据是否应该让每个模型跟踪其关系提出了一个问题：SQL relationships and best practices

这方面的一个例子是一个“页面”表，它说明了它的作者是谁......问题似乎是，如果 2 个用户是一个页面的作者，你必须添加一个新的特定表称为 PageRelationshipsWithUsers 可能具有对 PageID 和创建它的 UserID 的引用以及共同作者的单独行。

可以理解，这听起来有点不妥。我最终会得到一大堆关系表，而且很可能只用一个多用途关系表来代替它......所以我决定想出一个如下所示的关系表：

关系表新

RelationshipID | ItemID        | LinkID     | ItemType    | LinkType | Status
-----------------------------------------------------------------------------
1              | 23(PageID)    | 7(UserID)  | ("Page")    | ("User") | TRUE
2              | 22(CommentID) | 7(UserID)  | ("Comment") | ("User") | TRUE
3              | 22(CommentID) | 23(PageID) | ("Comment") | ("Page") | TRUE

但是，我非常感谢一些关于像这样布置我的关系表的想法有多好的意见。

有什么想法吗？

一位同事告诉我的答案：

想象一下模型“Book”的上述关系表

一个用户可以租一本书，所以关系是用户 -> 书... 但是如果他也可以买一本书呢：User->Book....

糟糕，我们需要一个新的关系...考虑到这个关系表应该是一刀切，我们现在需要添加一个新的单独的表...哎呀。

所以答案是不不不。不要，很淘气。保持您的关系表独立且具体。

Answer 1

您对关系表的建议不是最优的，原因如下：

• 很难编写通过关系表连接表的查询，因为您需要对 ItemType 和 LinkType 列进行过滤，这在编写查询时并不直观。
• 如果将来需要添加新的实体，这些实体使用不同的数据类型作为主键，您不能轻松地将各种数据类型的 ID 存储在 ItemID 和 LinkID 列中。
• 您不能在数据库中创建显式外键来强制引用完整性，这可能是避免您建议的设计的最佳理由。
• 查询性能可能会受到影响。

在规范化数据库时，您不应该害怕拥有许多表。只需确保使用有意义且自记录的命名约定即可。例如，您可以将作者和页面之间的关系表命名为“PageAuthors”，而不是“Pages”。