mysql评论回复表设计_数据库设计——评论回复功能
1、概述
评论功能已经成为APP和⽹站开发中的必备功能。本⽂主要介绍评论功能的数据库设计。
评论功能最主要的是发表评论和回复评论(删除功能在后台)。评论功能的拓展功能体现有以下⼏⽅⾯：
(1)单篇⽂章的评论数量和信息展⽰；
(2)从时间维度，按照时间倒叙的⽅式展⽰动态的⽤户评论信息；
(3)不同栏⽬，不同模块，不同时间维度的评论排⾏展⽰；
(4)精华评论的单独推荐和聚合展⽰；
(5)评论后直接分享到绑定的第三⽅平台；
(6)点赞数、回复数等维度的排⾏等。
评论的后台管理：
随机数公示
(1)删除；
(2)推荐；
(3)精华；
(4)屏蔽，敏感关键字的库的完善、⾃动屏蔽或者替换功能。
本篇⽂章主要分析⼏种客户端评论数据表的设计。
2、数据表设计
2.1 ⼀问⼀答模式
(1)需求分析
⼤部分APP采⽤简单的评论设计即可，即是⼀问⼀答模式，⽐如朋友圈的评论功能的设计。如：
A：今天天⽓真好！
B @ A ：今天天⽓确实不错！
1
2
这种设计简单、直接，也满⾜了⽤户评论、回复的基本要求，对于没有⼤量⽤户评论的APP需求⾜够。
export软件什么意思(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格式，可以应付简单的展现需求。
2.2 评论为主模式
(1)需求分析
如果以评论为主的显⽰模式，类似于下⾯的CSDN的评论显⽰模式：
mysql面试题csdn这⾥将评论分为评论和回复，所有评论均挂在评论下⾯，类似于树状结构。
(2)数据库设计
在以评论为主的树形显⽰情况下，数据库的设计⼗分灵活，可以使⽤单表，添加⼀个parent_id字段来指向⽗评论，需要嵌套查询。
同时也可以将评论拆分为评论表和回复表，评论挂在各种主题下⾯，⽽回复挂在评论下⾯。
评论表设计如下：
表字段字段说明
id
主键
topic_id
matlab的figure函数用法主题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的话，这表⽰这条回复的⽗回复。
2.3 ⽹易新闻盖楼模式
(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来到对应的路径。
闭包表在查询时⾮常⽅便，但是插⼊的性能稍差，因为除了插⼊评论表以外，还需要把该条评论所有的⽗⼦关系插⼊到⽗⼦关系表中。 插⼊性能会随着评论层级的加深⽽线性下降。输入的数组与初始化的数组
3、数据库优化c语言中sqrt函数怎么用
如果你的系统每天都会拥有成千上万条评论，那么单表的设计肯定是不⾏，优化的⽅式有以下⼏种思路。
(1)分库分表。 分库分表是最为常⽤也最有效的优化⽅式，建议按照主题来分库分表。 这样同⼀个主题下⾯的评论就会落到同⼀张表⾥，避免了跨表查询。
(2)适当的数据冗余。 如果你需要显⽰评论⼈的相关信息，那么在插⼊评论时就把这些信息写⼊评论表中，避免多次查询。 实际上，如果是纪录数据，都可以冗余对应的数据信息，因为它们的数据的实时⾏和⼀致性要求并不⾼。
(3)附加幂。数据只允许单项操作。 因为从幂性的要求来说，每个赞全都是⼀条记录。 评论的赞数如果都从点赞表中统计得出，那么性能开销会⼗分巨⼤，⽽且点赞如此轻量级的⼀个操作⼀定会加剧点
赞表的竞争操作。 所以建议直接在评论表中添加⼀个like_count的计数器，该字段只增不减。客户端，可以设置取消效果。
(4)热门评论加缓存。 类似于⽹易新闻的热门评论，读取频度⾮常⾼，可以专门开接⼝做缓存。