数据库设计——评论回复功能.docxVIP

数据库设计——评论回复功能 2021-09-04 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字段来指向父评论，需要嵌套查询。 同时也可以将评论拆分为评论表和回复表，评论挂在各种主题下面，而回复挂在评论下面。 评论表设计如下： 回复表设计： 由于我们拆分了评论和回复，那么评论表就不再需要目标用户字段了，由于评论均是用户对主题的评论，评论表的设计更佳简约了。 回复表添加了一个comment_id字段来表示该回复挂在的根评论id，这样设计也是出于功能方面的考虑，我们可以直接通过评论id一次性的找出该评论下的全部回复，然后通过程序来编排回复的显示结构。 通过适当的冗余来提高功能也是常用的优化手段之一。 reply_type：表示回复的类型，由于回复可以是针对评论的回复(comment)，也可以是针对回复的回复(reply)， 通过这个字段来区分两种情景。 reply_id：表示回复目标的id，假如reply_type是comment的话，那么reply_id＝commit_id，假如reply_type是reply的话，这表示这条回复的父回复。 2.3 网易旧事盖楼模式 （1）需求分析 这种场景中评论和回复是同级显示的，回复不在显示结构上不用挂在一个评论下面。 双表的设计在这里就不太合适了，由于涉及到评论和回复的混排，使用双表则会导致查询的规律过于简单。 所以建议还是接受单表的设计，不区分评论和回复会简化应用层的规律。 我们统一都看成评论，而有些评论是可以引用其他评论的。 （2）数据库设计 本人推举接受闭包表的设计，例如： parent_child表： comment表保存全部评论内容，而parent_children表则记录评论表中各个评论的父子关系。 查询时往往会依据时间排序，我们可以直接按id或者创建时间降序陈列查询comment表即可。 假如用户想查询一条评论的完整引用，则可以通过parent_children来找到对应的路径。 闭包表在查询时格外便利，但是插入的功能稍差，由于除了插入评论表以外，还需要把该条评论全部的父子关系插入到父子关系表中。 插入功能会随着评论层级的加深而线性下降。 3、数据库优化 假如你的系统每天都会拥有成千上万条评论，那么单表的设计确定是不行，优化的方式有以下几种思路。 （1）分库分表。 分库分表是最为常用也最有效的优化方式，建议依据主题来分库分表。 这样同一个主