当前位置：首页 > article >正文

多级评论单表结构设计

article 2025/1/19 14:23:14

这里的多级，本质上其实也就二级，例如微博的评论，

一级评论：对微博的评论

二级评论：对微博下的评论的回复评论，这里包括二种 1. 回复的是一级评论， 2, 回复的是二级评论

效果如下

表数据

查询文章评论时：

SELECT * from comment where article_id = '1' and comment_level = 1 ORDER BY top_status desc ,create_time desc

结果：

1 aaa 张三 1 标题党 1 一级评论(评论文章) 1 0 0 2019-04-26 17:37:48

查看评论下的回复时：

SELECT * from comment where parent_comment_id = '1' and article_id = '1' and comment_level = 2 ORDER BY create_time desc

结果：

3 aaa 张三 1 标题党 1 aaa 2 bbb 2 回复二级评论 1 0 0 2019-04-26 17:40:04
2 bbb 李四 1 标题党 1 aaa 2 回复一级评论 1 0 0 2019-04-26 17:38:53

上面查询评论都是按照时间 create_time 倒叙，如果要改成微博的那种按照热度的或者点赞量的

只需要把create_time 改成 praise_num

-----------------------------------------------------------------------表结构如下--------------------------------------------------------------------------------------------

id 评论id 可以设置为自增主键也可设置为uuid
user_id 评论人userId
user_name 评论人昵称，记录当时评论的时候用户的昵称，如果用户昵称修改，评论展示也变的话不需要设置该字段
article_id 在哪篇篇文章下评论的
article_title 文章标题，记录当时评论的时候文章标题，查看我的评论或者评论我的时，文章动态获取的话不需要设置该字段
parent_comment_id 父级评论id
parent_comment_user_id 父级评论的userid
reply_comment_id 被回复的评论id
reply_comment_user_id 被回复的评论的userid
comment_level 评论级别，回复文章的是一级评论，其它的都是二级评论
content 评论内容
status 评论状态，评论被删除了都是逻辑删除，不会真实删除
praise_num 评论的点赞数量
top_status 评论是否置顶
create_time 评论创建时间
表结构为

CREATE TABLE `comment` (
  `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论id',
  `user_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论人userId',
  `user_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '评论人名称',
  `article_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论的文章id',
  `article_title` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '评论的文章标题',
  `parent_comment_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '父评论id',
  `parent_comment_user_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '父评论的用户id',
  `reply_comment_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '被回复的评论id',
  `reply_comment_user_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '被回复的评论用户id',
  `comment_level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '评论等级[ 1 一级评论 默认 ，2 二级评论]',
  `content` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '评论的内容',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态 (1 有效，0 逻辑删除)',
  `praise_num` int(11) NOT NULL DEFAULT '0' COMMENT '点赞数',
  `top_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '置顶状态[ 1 置顶，0 不置顶 默认 ]',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`),
  KEY `idx_article_id` (`article_id`) USING BTREE,
  KEY `idx_user_id` (`user_id`) USING BTREE,
  KEY `idx_create_time` (`create_time`),
  KEY `idx_parent_comment_id` (`parent_comment_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='文章评论表';

1. 编码设置为 utf8mb4 是为了支持 emoji 标签

2. id 根据需求可以设置为自增或者 uuid

3. user_name 字段和 article_name 字段根据需要来是否设置为表字段。如果为表字段就不用连表查询，但是记录的都是当时评论的时候的用户名和文章标题。好在用户昵称和文章标题变化但是对应的 id 是不变的，也可以关联查询到。

4. 文章id ，用户id 创建时间，父评论id 设置索引在查询时都能有效利用索引

5. 评论删除功能，其实都不是真实物理删除，只是设置不可见，（支持消息中心以及我的评论）

查看全文

http://www.kler.cn/a/4131.html