一张桌子 vs 多张桌子答案

【问题标题】：One table vs multiple tables一张桌子 vs 多张桌子
【发布时间】：2012-05-23 01:44:34
【问题描述】：

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

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

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

第一个解决方案

cmets 表（comment_id、author_id、comment）
4 个表来创建关系（posts_cmets(post_id, comment_id), files_cmets(file_id, comment_id), events_cmets(event_id, comment_id), documents_cmets(document_id, comment_id)）

第二种解决方案

cmets 表（comment_id、author_id、comment）
items_cmets (comment_id, parent_type (enum['post', 'file', 'event', 'document']), parent_id)

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

【问题讨论】：

我更喜欢第一种解决方案，要灵活一些，因此您必须通过编辑 1 个名称（如果需要）将名称文件更改为文件，而不是在第二种解决方案中的 items_cmets 表中。 Als 尝试理解数据库规范化en.wikipedia.org/wiki/Database_normalization

【解决方案1】：

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

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

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

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

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：