3

我有以下表格： - 帖子 - 文件 - 事件 - 文档

每个帖子、文件、事件、文档都可以有评论。

什么是更好的数据库方案，为什么？

第一个解决方案

  • 评论表（comment_id、author_id、comment）
  • 4个表来创建关系（posts_comments（post_id，comment_id），files_comments（file_id，comment_id），events_comments（event_id，comment_id），documents_comments（document_id，comment_id））

第二种解决方案

  • 评论表（comment_id、author_id、comment）
  • items_comments (comment_id, parent_type (enum['post', 'file', 'event', 'document']), parent_id)

什么是更好的解决方案，或者我应该使用两者中的哪一个？

4

3 回答 3

2

想要/需要一个评论表可能有真正的原因。例如，它会使查看给定用户的所有评论变得更简单。此外，搜索所有评论会更简单（在一张表上放置一个 FTS 索引就完成了）。

另一方面，如果没有令人信服的理由将评论保留在单个表格中，则可能存在第三种（而且相当明显）的解决方案。

为每个项目（帖子、事件、文件、文档）创建一个单独的评论表。在那种情况下定义和描述 RI 关系将非常简单。此外，如果您经常键入临时查询，它可能会使其更简单。例如

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

这些都可能与您的情况无关或不重要，但可能值得考虑。

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

于 2012-05-15T16:27:34.987 回答
1

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

于 2012-05-15T14:16:16.597 回答
1

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

在此处输入图像描述

于 2012-05-15T19:52:03.857 回答