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

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”的上述关系表

用户可以租借书籍，因此关系是用户 - ＆gt;书... 但如果他也可以买书怎么办：用户 - ＆gt;预订......

哎呀，我们需要一个新的关系...并且考虑到这个关系表应该是1个大小适合所有，我们现在需要添加一个新的单独表...哎呀。

所以答案是NO NO NO。不，这很顽皮。保持关系表的独立性和特定性。

Answer 1

由于以下几个原因，您对关系表的建议并不理想：

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

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