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，而目标用户的信息再去查询缓存或者数据库。