一张表 vs 多张表

Question

我有以下表格：

- 帖子 - 文件 - 活动 - 文档

每个帖子、文件、活动和文档都可以有评论。

对于这个问题，什么是更好的数据库方案，为什么？ 第一种解决方案

• 评论表（评论ID、作者ID、评论）
• 4个表来创建关系（posts_comments（帖子ID、评论ID）、files_comments（文件ID、评论ID）、events_comments（活动ID、评论ID）、documents_comments（文档ID、评论ID））

第二种解决方案

• 评论表（评论ID、作者ID、评论）
• items_comments（评论ID、parent_type（枚举['post'、'file'、'event'、'document']）、parent_id）

哪种方案更好，或者我应该使用其中的哪一个？

- Tamás Pap

---

我更喜欢第一种解决方案，因为它更灵活，你只需要编辑一个名称（如果你想的话），而不是在第二个解决方案中所拥有的items_comments表中的所有名称都要更改为files。同时，请尝试理解数据库规范化http://en.wikipedia.org/wiki/Database_normalization。 - Ron van der Heijden

Answer 1

可能有一些真正的原因需要/需要单个评论表。例如，这将使查看给定用户的所有评论变得更简单。此外，通过所有评论的搜索将更加简单（在一个表上放置一个FTS索引即可）。

另一方面，如果没有强制保留评论在单个表中的理由，那么可能有第三种（而且相当明显的）解决方案。

为每个项目（帖子、事件、文件、文档）创建单独的评论表。在这种情况下，RI关系非常容易定义和描述。此外，如果您经常输入即席查询，它可能会变得更简单。例如：

 select * from documents d left join doc_comments c 
                           on d.id = c.docid 
                           where d.id=42;

这些内容可能与您的情况无关紧要，但值得考虑。

另一个随机想法：OP中的两个解决方案都给人一种“感觉”，即它们定义了多对多的关系（例如，评论可以属于多个项目）。假设这不是期望的情况，可以通过适当的唯一索引来防止它...但是...它具有初始外观，似乎可能导致混淆。

- Mark Wilkins

Answer 2

我更喜欢第一种解决方案。那里的SQL语句更简单。而且在我看来，它更符合数据库规范化。

- Tomtom

Answer 3

为了完整起见，我应该提到另一个可能性 - 继承（也称为泛化或（子）类别层次结构）：

- Branko Dimitrijevic