MySQL文章中是否储存评论的id

MySQL文章中是否储存评论的id

在设计一个文章系统的数据库结构时，一个常见的问题是是否应该在文章表中储存评论的ID，或者是通过另外一种方式来处理评论。在这篇文章中，我们将探讨这个问题，并分析不同的方案的优缺点。

表设计方案

假设我们有两个表：文章表（articles）和评论表（comments）。文章表用来存储文章的内容，而评论表用来存储对文章的评论。最简单的设计方案是在文章表中添加一个字段来存储评论的ID，我们可以称之为comments_id。另外一种设计方案是仅仅在评论表中存储评论内容和相关信息，而不在文章表中储存评论的ID。

方案一：在文章表中储存评论的ID

表结构

articles
----------
id (INT, PK)
title (VARCHAR)
content (TEXT)
comments_id (INT)

comments
----------
id (INT, PK)
article_id (INT, FK)
content (TEXT)

在这种方案下，我们在文章表中添加了一个comments_id字段，用来存储评论的ID。当用户发表评论时，我们将评论的ID存储在comments_id字段中，这样我们就可以通过文章表来查找与文章相关的评论。

优点

• 简单直观：这种方案比较直观，容易理解和实现。
• 高效性能：通过文章表来查找评论也比较高效，可以直接通过索引快速定位到对应的评论。

缺点

• 数据冗余：在文章表中存储评论的ID会导致数据冗余，可能会占用一定的存储空间。
• 一致性问题：当评论表中的评论发生变化时，需要同步更新文章表中的评论ID，容易出现一致性问题。

方案二：仅在评论表中存储评论内容

表结构

articles
----------
id (INT, PK)
title (VARCHAR)
content (TEXT)

comments
----------
id (INT, PK)
article_id (INT, FK)
content (TEXT)

在这种方案下，我们仅在评论表中存储评论的内容和相关信息，而不在文章表中储存评论的ID。通过article_id字段来关联评论和文章。

优点

• 避免数据冗余：不在文章表中存储评论ID避免了数据冗余的问题。
• 数据一致性：避免了方案一中出现的一致性问题。

缺点

• 查询效率：需要通过评论表来查找与文章相关的评论，可能会降低查询的效率。

结论

在实际应用中，选择是否在文章表中存储评论的ID取决于具体的需求。如果是一个小型的系统，且评论数量不是很大，方案一是一个简单而有效的设计方案。而对于大型系统来说，可能更倾向于方案二，避免数据冗余和一致性问题。

在设计数据库表结构时，需要考虑具体的业务需求和系统规模，权衡各种方案的优缺点，选择适合自己系统的设计方案。