ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

论坛系统数据库设计

2022-10-05 13:40:26  阅读:218  来源: 互联网

标签:


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.推荐设计

标签:
来源:

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有