数据库的通用关系

Question

我必须设计一个通用实体，该实体能够引用不同的其他实体。

在我的示例中，这将是 Web 应用程序中的 commentary 实体。您可以在users、classifieds、articles、varieties（植物类）等上发表评论。

所以实体会变成这样：

事实上，设计（某种）模式是这样的：

这种模式的优缺点是什么？

我看到的是：

优点

• 如果概念相同（例如注释），它会减少实体的数量；
• 因此您可以轻松操作异构对象；

• 您可以轻松地聚​​合这些对象（例如，该用户在整个站点中的最后评论，在同一线程中轻松呈现）；

  缺点

• 这会让你陷入丑陋的境地（你粗暴地使用它，你的数据库和源代码都很丑陋）；

• 数据库中没有控制，因此必须在应用程序代码中完成。
• 对性能有什么影响？

结论

这种模式适合关系型数据库吗？那我们该怎么办呢？

提前谢谢你。

Answer 1

还有一个缺点：

此方案依赖于这些值所引用的“实体”的值和名称之间的映射。想想在 TEST 系统中解决问题的所有乐趣，ORDER 实体的编号为 734，但在生产中，它的编号为 256。您可以使用实体名称本身作为 entity_id 内容的值，但您会无论如何，永远无法避免在程序中（或者说，在视图定义中）为它们硬编码值。从而击败您认为可以获胜的任何优势。

这种方案是OO程序员最常患的病。他们看到的结构大体相似，他们有这种本能的反应“我必须为此找到一种方法来恢复现有的东西”。忘记数据库设计不是程序设计。

编辑

（如果不清楚，这意味着我对您的问题“这种模式是否适合关系数据库？”的回答是原则上的“否”。）

Answer 2

这是经典的多态关联反模式。有许多可能的解决方案：

1) 独家弧线，例如用于评论实体

Id
User_Id
Classified_Id
Article_Id
Variety_Id

其中 User_Id、Classified_Id、Article_Id 和 Variety_Id 可以为空，且其中一个不得为空。

2) 反转关系，例如从 Commentary 实体中删除 Target_Entity 和 Target_Entity_Id 并创建四个新实体

用户评论

Commentary_Id
User_Id

分类_评论

Commentary_Id
Classified_Id

Article_Commentary

Commentary_Id 
Article_Id

Variety_Commentary

Commentary_Id
Variety_Id

Commentary_Id 是唯一的并且与 Commentary 中的 Id 相关。

3) 为 User、Classified、Article 和 Variety 创建一个超类型实体，并让 Commentary 实体引用这个新实体的唯一属性。

您需要决定您认为哪种方法最适合您的具体情况。