评论系统的几种展示结构和存储设计
评论系统的几种展示结构和存储设计
评论系统是互联网社区网站的重要组成部分,对增强用户参与度、提高网站活跃度等方面都具有重要价值。评论系统的基本功能主要包括:用户发表评论、读取评论、回复评论等(现代评论系统可能还包括排序、过滤、搜索等功能)。
为提升评论系统的用户体验,评论系统需要有良好的展示结构和存储设计,以支持大量的用户并发访问和大量的数据存储。本文将介绍三种常见评论系统展示价格及其存储设计:
- 平铺式结构
- 嵌套式结构
- 混合式结构(二层嵌套)
一、平铺式(线性)评论结构
1. 什么是平铺式(线性)评论结构
线性结构,也被称为平面结构或直线式结构,是一种最简单也最常见的评论展示方式。在这种结构中,评论按照时间顺序排列,最新的评论可以放在最上面,也可以放在最下面,这取决于网站的设计。每条评论都是独立的,不与其他评论形成层级关系。这种结构简单明了,易于实现和理解。
线性结构的主要特点是:结构简单,易于浏览;不支持深度对话,因为回复无法直接关联到特定的评论;适合对话较少或者对话不重要的场景。
2. 适用场景和例子
线性结构的评论系统适用于对话不是主要目的,或者用户更关注新鲜内容的场景。例如新闻网站、博客网站等,用户通常更关注文章本身,而不是其他用户的评论。他们可能会浏览一下最新的评论,但不太可能深入到评论的对话中。
另一个例子是电商网站的商品评价,用户通常会浏览最新的评价或者最有帮助的评价,而不会关注评价之间的对话。因此,线性结构的评论系统就足够满足需求。
- 微信朋友圈
- Github issue
3. 存储设计摘要
直线式评论展示结构因为复杂的评论回复关系,其存储设计也比较简单。
不考虑缓存等逻辑,可以参照下面的表设计
字段名 | 数据类型 | 描述 |
---|---|---|
comment_id | INT | 评论的唯一标识符,通常是一个自增的整数。 |
user_id | INT | 发表评论的用户的唯一标识符。 |
content | TEXT | 评论的文本内容。 |
post_time | TIMESTAMP | 评论被发表的时间,可以用来排序评论。 |
target_id | INT | 评论所针对的对象的唯一标识符,例如一个文章、产品或其他用户。 |
reply_to_id | INT | 被回复或引用的评论的唯一标识符。如果这个评论不是回复或引用其他评论,那么这个字段可以为空。 |
二、嵌套式(树形)评论结构
1. 什么是嵌套式(树形)评论结构
嵌套式(树形)评论结构是一种常见的在线评论组织方式,它允许用户在其他用户的评论下面进行回复,形成一种层次分明的对话结构。这种结构通常被可视化为一棵树,其中根节点是原始帖子,每个子节点是对父节点的回复。
嵌套式评论结构的特点包括:
- 层次性:每个评论都可以有一个或多个子评论,形成一个层次分明的对话结构。这种层次性使得用户可以轻松地追踪和参与特定的讨论线程。
- 上下文相关性:由于每个评论都是对特定评论的回复,因此它们通常在上下文中有明确的关联性。这使得读者可以更好地理解每个评论的含义和目的。
- 动态性:嵌套式评论结构允许新的评论在任何位置插入,无论是作为新的顶级评论,还是作为现有评论的回复。这种动态性使得讨论可以随着时间的推移而发展和演变。
- 可扩展性:嵌套式评论结构可以容纳任意数量的评论和回复,使得它可以轻松地扩展以适应大规模的在线讨论。
- 交互性:嵌套式评论结构鼓励用户参与讨论,因为他们可以直接回复其他用户的评论,而不仅仅是对原始帖子进行评论。这种交互性可以增加用户的参与度和满意度。
2. 使用场景和例子
嵌套式(树形)评论结构适用于许多在线交互场景,特别是那些需要深度讨论和多层次对话的场合。
下面是一些使用嵌套式树形结构的站点
3. 树形评论结构的存储设计
树形评论结构的典型存储设计通常有两种主要的方法:邻接列表模型和路径枚举模型。
- 邻接列表模型:在这种模型中,每个评论都有一个父评论ID字段。顶级评论的父评论ID通常设置为null或特定的值。这种方法的优点是数据结构简单,易于理解和实现。但是,查询特定评论的所有子评论或者查询特定评论的所有祖先评论可能需要多次查询数据库,效率较低。
字段名 | 数据类型 | 描述 |
---|---|---|
id | int | 评论的唯一标识 |
parent_id | int | 父评论的id,顶级评论的父评论id可以为null或特定的值 |
content | text | 评论的内容 |
- 路径枚举模型:在这种模型中,每个评论都有一个路径字段,记录了从顶级评论到当前评论的路径。例如,如果评论B是评论A的子评论,评论C是评论B的子评论,那么评论A的路径可能是"A",评论B的路径可能是"A/B",评论C的路径可能是"A/B/C"。这种方法的优点是查询特定评论的所有子评论或者查询特定评论的所有祖先评论只需要一次查询数据库,效率较高。但是,插入新的评论或者移动评论可能需要更新多条记录的路径,效率较低。
字段名 | 数据类型 | 描述 |
---|---|---|
id | int | 评论的唯一标识 |
path | text | 从顶级评论到当前评论的路径,例如"A/B/C" |
content | text | 评论的内容 |
三、混合式评论结构(二层嵌套结构)
1. 二层嵌套评论结构
二层嵌套评论结构是一种常见的在线评论组织方式,它允许用户对一个主题进行评论,同时也可以对其他用户的评论进行回复。
这种结构通常表现为一个主评论(也称为根评论或顶级评论)下面跟随着一系列子评论。对子评论的回复更多是引用关系、而非父子关系,他们的父节点都是主评论。
这种结构的主要优点是它可以方便地跟踪和组织讨论的线索,使得用户可以更容易地理解和参与到讨论中。同时限制评论层级,又不至于让用户过度沉浸在评论的交互中,回归主题。
2. 二层嵌套评论结构的适用场景合理
二层嵌套评论结构广泛应用于各种在线社区、论坛、博客和新闻网站等,它允许用户对主题进行评论,同时也可以对其他用户的评论进行回复(对一级评论的回复以父子节点形式组织,对二级评论的回复以平铺方式组织)。
大多数国内的社区、论坛、视频站点都采用这种二层嵌套的评论结构。
- 知乎
- B站
3. 二层嵌套评论结构的存储设计
Field | Type | Description |
---|---|---|
comment_id | INT | 每个评论的唯一标识符,主键 |
parent_id | INT | 每个评论的父评论的comment_id,对于一级评论,这个字段为NULL |
topic_id | INT | 每个评论所属的主题的ID |
content | TEXT | 评论的内容 |
user_id | INT | 发表评论的用户的ID |
post_time | TIMESTAMP | 评论的发表时间 |
reply_to_id | INT | 被回复或引用的二级评论的唯一标识符。如果这个评论不是回复或引用其他评论,那么这个字段可以为空。 |