留言评论功能的数据库设计

1、概述

评论功能已经成为APP和网站开发中的必备功能。本文主要介绍评论功能的数据库设计。

  • 评论功能最主要的是发表评论和回复评论。
  • 评论功能的拓展功能体现有以下几方面:
  • 单篇文章的评论数量和信息展示;
  • 从时间维度,按照时间倒叙的方式展示动态的用户评论信息;
  • 不同栏目,不同模块,不同时间维度的评论排行展示;
  • 点赞数、回复数等维度的排行等。

评论的后台管理:

  • 删除;
  • 推荐;
  • 精华;
  • 屏蔽,敏感关键字的库的完善、自动屏蔽或者替换功能。

数据表设计

(本文讨论两种模式)

评论为主模式

  • 需求分析
    类似于CSDN这种以评论为主的模式,分为评论和回复。
    留言评论功能的数据库设计
    把所有回复都放在评论下面,类似于树状结构。

  • 数据库设计
    在以评论为主的树形显示情况下,可以将评论分为评论表和回复表。评论挂在主题下面,而回复挂在评论下面

评论表:

表字段 字段说明
id 主键
topic_id 主题id
topic_type 主题类型
content 评论内容
from_uid 评论用户id

回复表:

表字段 字段说明
id 主键
comment_id 评论id
reply_id 回复目标id
reply_type 回复类型
content 回复内容
from_uid 回复用户id
to_uid 目标用户id

由于我们拆分了评论和回复,那么评论表就不再需要目标用户字段了,因为评论均是用户对主题的评论,评论表的设计更佳简洁了。

reply_type:表示回复的类型,因为回复可以是针对评论的回复(comment),也可以是针对回复的回复(reply), 通过这个字段来区分两种情景。

reply_id:表示回复目标的id,如果reply_type是comment的话,那么reply_id=commit_id,如果reply_type是reply的话,这表示这条回复的父回复。

一问一答模式

  • 需求分析

简单的评论设计,但适用于很多app。比如微信朋友圈
留言评论功能的数据库设计
这种设计简单、直接,也满足了用户评论、回复的基本要求,对于没有大量用户评论的APP需求足够。

  • 数据库设计

这种场景下评论一般较少,不区分评论与回复。使用一张表就可以达到效果。

表字段 字段说明
id 主键
topic_id 主题id
topic_type 主题类型
content 评论内容
from_uid 评论用户id
to_uid 评论目标用户id

topic_type:为了能复用评论模块,我们引入这个字段来区分主题的类别。

from_uid:表示评论人的id,通过该id我们可以检索到评论人的相关信息。

to_uid 是评论目标人的id,如果没有目标人,则该字段为空

出于性能的考虑,往往我们会冗余评人的相关信息到评论表中,比如评论人的nick、头像,目标用户也是如此。 这样一来我们就只用查询单表就可以达到显示的效果

有时,目标用户有多个,那么可以将to_uid字段修改为to_uids,保存时用分隔符来分割用户id,而目标用户的信息再去查询缓存或者数据库。也可以简单的将多个目标用户的信息一起存成json格式,可以应付简单的展现需求。

留言评论功能的数据库设计

上一篇:modbus rtu客户端转modbus tcp服务器


下一篇:5种mysql中Sequence实现,基于锁,高并发,唯一性等场景