关系型数据库中“评论”表的最佳实践

Question

假设您想为某个Web应用程序构建数据库。该数据库已经包含了许多表格，您可能将来需要扩展它。

此外，您希望最终用户能够评论数据库中的任何对象。

我想找到一个足够通用的解决方案，这样我就不必每次向数据库添加新表时都进行扩展。

我想到了以下内容： 表名：comment 列：

- id: 评论的ID - user_id: 进行评论的用户ID - object_table_name: 被评论对象所在的表 - object_id: 被评论对象在object_table_name表中的ID。 - text: 文本 - date: 日期

这个表在某种程度上解决了我的问题，唯一让我困扰的是它的关系方面相当弱（例如，我无法将object_id作为外键）。此外，如果有一天我需要重命名一个表，我将不得不更改评论表中涉及的所有条目。

您认为这个解决方案怎么样？是否有设计模式可以帮助我？

谢谢。

- Alexandre

---

你需要保留这些评论的历史记录吗？我想不出其他重要理由来创建任何类型的独立评论表。 - jwheron

每个(object_table_name, object_id)组合对应多个评论，是否可行？如果始终是1:1，则只需将评论作为object_table_name本身的额外列包含在内。如果是1：N，则需要一个单独的表。 - Yevgeniy Brikman

Answer 1

这难道不更清晰明了吗？

表格 comment_set

• id

表格 comment

• id
• comment_set_id -> 外键关联到 comment_set
• user_id
• date
• text

现有的表格 foo

• ...
• comment_set_id -> 外键关联到 comment_set

现有的表格 bar

• ...
• comment_set_id -> 外键关联到 comment_set

- Nicolas Repiquet

---

那么，除非你注释掉它，否则你将无法向 foo 或 bar 插入数据？ - Quassnoi

@Quassnoi 为什么？外键可以为空，或者注释集可以为空。 - Nicolas Repiquet

为什么要拥有它们呢？另外，您如何确保foo和bar不引用相同的comment_set？ - Quassnoi

你不能这样做。基本上，每个“可评论实体”都可以指向一个包含“评论”的“评论集”。你可以通过引用null或空的评论集来表示给定实体的缺少评论。 - Nicolas Repiquet

这对我来说听起来是个好主意。我可以在代码中处理数据一致性问题，这不应该是个问题。 - Alexandre

Answer 2

您正在混合数据和元数据，这不是最佳的设计模式。它们应该分开。

然而，既然评论似乎并不是非常重要，您的解决方案就可以了。你可能会因此失去对象上的评论，但那也不是什么大事。

一些数据库，尤其是PostgreSQL，支持COMMENT语句，专门用于这种情况。

更新：

如果您想对每个表中的单个记录进行注释，拥有这样一张表就可以了。

由于它是数据而不是元数据，所以即使您重新命名了表，object_table_name也不必更改。

您无法编写本地SQL查询来获取任何表的记录的注释（在查询开发时未知），但您可以构建动态查询来实现这一点。

在这种情况下，您需要保持数据和元数据同步（当您重命名它们所指向的表时，更新评论表）。第一个是DML语句（更改数据），第二个是DDL语句（更改元数据）。

还要确保所有主键都具有相同类型（与object_id相同）。

- Quassnoi

---

我认为 OP 希望用户对 ROWS（向用户展示的对象）发表评论，而不是像表或索引这样的数据库对象。 - Larry Lustig

@Larry：你可能是对的，但从帖子中并不那么明显 :) - Quassnoi

是的，抱歉造成了歧义。我需要对表格的行进行注释。 - Alexandre

Answer 3

阅读有关EAV的内容。 您可以将整个数据库都设置为这样。但是，使用该数据将会很麻烦。

为什么不为每个支持评论的数据库实体放置一个Comment属性呢？这样，您可以在单个查询中获取所需的所有数据，并且许多数据库的GUI程序将为您提供完整的SQL代码完成，从而防止在操作字符串时可能出现的错误。这样，代码就严重依赖于过程性代码，这对于数据库系统来说是不正确的。

- Alex

Answer 4

你可以在另一个表格中枚举表格名称，这样名称的更改不会对系统产生任何重大影响。只需更新枚举表即可。

虽然你正在远离参照完整性，但我可以看到实现你想要的另一种方式。

- Gabriele Petrioli

Answer 5

我通常喜欢将注释与它们所应用的行一起保留。假设您的数据库有效地存储空的VARCHAR字段，那么您不应该为此付出代价。当您实施这种方法时，没有什么需要“扩展”的，注释的维护成为您已经使用的更新行查询的一部分。

单独的注释表方法唯一的优点是它允许轻松搜索不同类型的数据库条目的注释。

- Larry Lustig

Answer 6

假设使用 MS SQL，如果数据量相对较小，正如您所暗示的那样，那么扩展属性可能值得探索。我过去曾经成功地使用过它们，它们似乎是一个永久的解决方案。

- smirkingman