在建站过程中遇到的第一个设计问题，就是文章与评论再数据库中如何存储，

这里有两个常见的存储方式，第一种是文章与评论储存在一张表中

内容与评论在一张表中存储

先看代码

{
    id:"",
    content:"",
    title:"",
    create_time:"",
    comments:[{
          id:"",
          content:"",
          autrhor:"",
          create_time:""
        },
        {...},
        {...}
    ],
}

表字段

字段说明

Id

文章的id，自增值，每个文章都对应一个唯一的id，也可以使用随机值但要不重复

content

文章的内容

author

文章作者

comment

文章的评论，以数组的形式存储所有评论

create_time

文章产生日期

这样在获取文章内容的时候就获取了评论，适合于评论不多并且没有评论盖楼的形式。

这样做的优点有几个：

•  读取数据时不需要进行连接操作，速度更快。

•  数据结构更简单，易于理解和维护。

•  适合存储一对一或者一对少数的关系数据。

缺点也有几个：

•  如果内容和评论的数量很多，可能会导致文档过大，超过数据库对单个数据的限制。

•  如果需要更新内容或者评论，可能会涉及到修改多个文档，增加复杂度和错误风险。

•  如果需要对评论进行分页或者排序，可能会影响性能和内存消耗。

 

评论与内容分开两张表存储

分开存储就是在评论的表中多加一个字段指向文章，

代码如下

 

{
//文章的表为
{
    id:"",
    content:"",
    create_time:"",
    title:"",
}
//评论为
{
  id:""
  parent_id:""  // 记录这是那一篇文章的评论
  content:""，
  author："",
  create_time:"",
}

}

表字段

字段说明

id

评论的id，自增值，每个评论都对应一个唯一的id, 也可以是随机不重复的数值

content

评论的内容

author

发出该评论的用户

parent_id

指向文章的id

create_time

评论产生日期

在需要加载评论的时候 查询所有评论找到与文字匹配的评论，

这里可能会有朋友认为查询所有id会不会影响加载速度，其实在有索引的情况下查询速度是很快的，

可以参考这片文章

在有索引的情况下一亿条数据查询时间只在毫秒级别，

使用两张表的优点：

•  数据更新时不需要修改多个文档，减少错误风险。

•  适合存储一对多或者多对多的关系数据。

缺点就很明显：

•  读取数据时需要进行连接操作，速度更慢。

•  数据结构更复杂，难于理解和维护。

•  如果需要对内容和评论进行联合查询，可能会影响性能和内存消耗。

 

对于到底使用哪一种存储方式，可以说各有优劣。一般来说，在数据量较小且查询频繁的情况下，可以使用单表设计；在数据量较大且插入和更新频繁的情况下，可以使用双表设计。

 

评论的回复

既然说到评论，还有一个评论的评论设计问题，也有两种常见的方法，

一种是给评论多加一个字段

 

{
    type:"article" // type:"comment"
}

当类型是article的时候说明是文章的评论 而类型的comment的时候就是对评论的回复，二者可以使用不用的渲染方式加以区分。

 

第二种就是在评论的内容，直接引用需要回复的内容比如

--------------------

author 发布于 2023年1月3日

@name  发布于2023年1月2日

beautiful

  thank you！

--------------------

如果是回复的回复就加多重引用就好了。