1、概述
评论功能已经成为APP和网站开发中的必备功能。
本文主要介绍评论功能的数据库设计。
评论功能最主要的是发表评论和回复评论（删除功能在后台）。
评论功能的拓展功能体现有以下几方面：
（1）单篇文章的评论数量和信息展示；
（2）从时间维度，按照时间倒叙的方式展示动态的用户评论信息；
（3）不同栏目，不同模块，不同时间维度的评论排行展示；
（4）精华评论的单独推荐和聚合展示；
（5）评论后直接分享到绑定的第三方平台；
（6）点赞数、回复数等维度的排行等。
评论的后台管理：
（1）删除；
（2）推荐；
（3）精华；
（4）屏蔽，敏感关键字的库的完善、自动屏蔽或者替换功能。
本篇文章主要分析几种客户端评论数据表的设计。
2、数据表设计
2.1 一问一答模式
(1)需求分析
大部分APP采用简单的评论设计即可，即是一问一答模式，比如微信朋友圈的评论功能的设计。
如：
A：今天天气真好！B @ A :今天天气确实不错！
这种设计简单、直接，也满足了用户评论、回复的基本要求，对于没有大量用户评论的APP需求足够。
（2）数据库设计
这种场景下一般评论较少，评论不活跃，可以不区分评论和回复，统一看成评论。
区别是，有些评论是直接评论主题，而有些是@其他用户，使用一张表就可以达到效果，评论表设计如下：
topic_type：
为了能复用评论模块，我们引入这个字段来区分主题的类别。
from_uid：
表示评论人的id，通过该id我们可以检索到评论人的相关信息。
to_uid 是评论目标人的id，如果没有目标人，则该字段为空
出于性能的考虑，往往我们会冗余评人的相关信息到评论表中，比如评论人的nick、头像，目标用户也是如此。
这样一来我们就只用查询单表就可以达到显示的效果
有时，目标用户有多个，那么可以将to_uid字段修改为to_uids，保存时用分隔符来分割用户id，而目标用户的信息再去查询缓存或者数据库。
也可以简单的将多个目标用户的信息一起存成json格式，可以应付简单的展现需求。
2.2 评论为主模式
(1)需求分析
如果以评论为主的显示模式，类似于下面的CSDN的评论显示模式：
这里将评论分为评论和回复，所有评论均挂在评论下面，类似于树状结构。
(2)数据库设计
在以评论为主的树形显示情况下，数据库的设计十分灵活，可以使用单表，添加一个parent_id字段来指向父评论，需要嵌套查询。
同时也可以将评论拆分为评论表和回复表，评论挂在各种主题下面，而回复挂在评论下面。
评论表设计如下：
