一、⼀问⼀答模式
(1)需求分析
⼤部分APP采⽤简单的评论设计即可,即是⼀问⼀答模式,⽐如微信朋友圈的评论功能的设计。如:
A:今天天⽓真好!
B @ A :今天天⽓确实不错!
这种设计简单、直接,也满⾜了⽤户评论、回复的基本要求,对于没有⼤量⽤户评论的APP需求⾜够。
(2)数据库设计
这种场景下⼀般评论较少,评论不活跃,可以不区分评论和回复,统⼀看成评论。区别是,有些评论是直接评论主题,⽽有些是@其他⽤户,使⽤⼀张表就可以达到效果,评论表设计如下:
表字段字段说明
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格式,可以应付简单的展现需求。
二、评论为主模式
(1)需求分析
A:今天北京天⽓真好!
B回复A:我们这⾥今天天⽓也不错!
A回复B:你是哪⾥的?
B回复A:安徽的。。。
C回复A:我们这⾥今天天⽓也不错!
A回复B:你是哪⾥的?
B回复A:安徽的。。。
这⾥将评论分为评论和回复,所有评论均挂在评论下⾯,类似于树状结构。
(2)数据库设计
在以评论为主的树形显⽰情况下,数据库的设计⼗分灵活,可以使⽤单表,添加⼀个parent_id字段来指向⽗评论,需要嵌套查询。
同时也可以将评论拆分为评论表和回复表,评论挂在各种主题下⾯,⽽回复挂在评论下⾯。
评论表设计如下:
表字段字段说明
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
由于我们拆分了评论和回复,那么评论表就不再需要⽬标⽤户字段了,因为评论均是⽤户对主题的评论,评论表的设计更佳简洁了。
回复表添加了⼀个comment_id字段来表⽰该回复挂在的根评论id,这样设计也是出于性能⽅⾯的考虑,我们可以直接通过评论id⼀次性的找出该评论下的所有回复,然后通过程序来编排回复的显⽰结构。 通过适当的冗余来提⾼性能也是常⽤的优化⼿段之⼀。
reply_type:表⽰回复的类型,因为回复可以是针对评论的回复(comment),也可以是针对回复的回复(reply), 通过这个字段来区分两种情景。
reply_id:表⽰回复⽬标的id,如果reply_type是comment的话,那么reply_id=commit_id,如果reply_type是reply的话,这表⽰这条回复的⽗回复。
三、⽹易新闻盖楼模式
(1)需求分析
这种场景中评论和回复是同级显⽰的,回复不在显⽰结构上不⽤挂在⼀个评论下⾯。 双表的设计在这⾥就不太合适了,因为涉及到评论和回复的混排,使⽤双表则会导致查询的逻辑过于复杂。 所以建议还是采⽤单表的设计,不区分评论和回复会简化应⽤层的逻辑。 我们统⼀都看成评论,⽽有些评论是可以引⽤其他评论的。
(2)数据库设计
本⼈推荐采⽤闭包表的设计,例如:
comment表设计:
表字段字段说明
id主键
topic_id主题id
topic_type主题类型
content评论内容
from_uid评论⽤户id
parent_child表:
表字段字段说明
id主键
parent_id⽗id
child_id⼦id
comment表保存所有评论内容,⽽parent_children表则记录评论表中各个评论的⽗⼦关系。
查询时往往会按照时间排序,我们可以直接按id或者创建时间降序排列查询comment表即可。 如果⽤户想查询⼀条评论的完整引⽤,则可以通过parent_children来找到对应的路径。
闭包表在查询时⾮常⽅便,但是插⼊的性能稍差,因为除了插⼊评论表以外,还需要把该条评论所有的⽗⼦关系插⼊到⽗⼦关系表中。 插⼊性能会随着评论层级的加深⽽线性下降。