论坛系统数据库设计


1.引言

2.1数据表设计猜测

数据字段 含义 comment_type 评论类型(dynamic或者comment) source_id dynamic_id或者comment_id comment_id 评论唯一编号 content 评论的具体内容 from_uid 发起评论的用户的唯一编号 date_time 评论的具体时间

补充说明:comment_type 用来标记数据是哪一一种类型,因为通过分析可以发现,用户的评论无非就是两种,一种是用户对于动态的直接评论,一种是对用户一级评论的回复。所以使用comment_type来标记是哪一种评论。source_id 标记评论是对哪种目标内容发起的,需要和comment_type联合判断,方便直接找到源头。如果评论的内容是一级评论,那么说明是直接针对动态发起的,对应就是dynamic_id;如果评论的内容是二级评论,那么对应的就是一级评论的comment_id。

2.2分析增删查改实现方法

一级循环,dynamic_id=>(comment_id,from_uid)集合; 二级循环,from_uid=>(一级评论者username);同时遍历comment_id的二级评论, 一级comment_id=>(二级comment_id,二级from_uid) 三级循环 ,二级from_uid=>(一级评论者username) 整理,带上content和comment_type两个字段返回给前端(方便前端展示), 形成一个json发给前端。

(4)修改数据,一般不支持修改,只有一种可能,系统查询敏感词,在发布的时候由后端修改关键词,也有的直接敏感词限制发布。

2.3分析QQ"摆烂式"的优缺点

    逻辑相对容易,最高只有二级评论,虽然有三层遍历,但是这些都是必要的。一个比较大的优点是,数据表空间利用率100%,单表,容易进行数据迁移。缺点,清晰度可能低一些,逻辑相对需要严谨一些,耦合度有点高,比如souce_id和comment_type的绑定。

2.4改进方法

    将数据表一分为二,一个表用来放一级评论,一个表用来放二级评论。这样就可以将souce_id解耦:

一级评论表

数据字段 含义 dynamic_id 动态id comment_id 评论唯一编号 content 评论的具体内容 from_uid 发起评论的用户的唯一编号 date_time 评论的具体时间

二级评论表

数据字段 含义 source_id 一级comment_id comment_id 评论唯一编号 content 评论的具体内容 from_uid 发起评论的用户的唯一编号 date_time 评论的具体时间

跨表查询,操作起来需要更换数据表,基本逻辑不变。     除此以外,可以将用户的username直接放到评论中,利用少量数据冗余优化性能,这也是数据库性能优化常用方法之一。

3.“盖楼式”设计

3.1数据表设计猜测

数据字段 含义 comment_type 评论类型(dynamic或者comment) source_id dynamic_id或者comment_id comment_id 评论唯一编号 content 评论的具体内容 from_uid 发起评论的用户的唯一编号 date_time 评论的具体时间

这个表行不行,行!不过有些顶,需要使用递归设计思想,或者改造的循环,算法难度蹭蹭蹭往上涨。咱这里就放个伪代码吧(我算法不好,没写太清楚):

function getcommentList(commnet_id, layer = 1) {
          
   //标记是哪一楼的
            //一级循环 => (二级comment_id,from_uid)集合;
            if ("二级comment_id集合为空 as commentList") {
          
   
                //处理数据
                const jsonExample={
          
   
                    layer:layer+"楼",
                    //...
                }
                return resultList;//返回疯转的数据
            } else {
          
   
                //"遍历{二级(其实就是低一级)}comment_id集合,顺带将from_uid转化成用户信息"
                for (let i = 0; i < commentList.length; i++) {
          
   
                    getcommentList(comnentList[i].comment_id, ++layer);
                }
            }
        }
        getcommentList(dynamic_id);

感觉:反复遍历,算法时间复杂度极高,何况还是对库操作,时间肯定是个问题,抗高并发能力较低,性能较差。增加数据倒还好,删除数据也需要递归删除所有低一层的评论(可能这个时候你不太想删了,哈哈哈,属实性能过差,但是等用户一层层往上差,发现那一层断了就可能影响用户体验)。

3.2数据表设计优化

4.推荐设计

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/290631.html

(0)
上一篇 2022年10月5日
下一篇 2022年10月5日

相关推荐

发表回复

登录后才能评论