论坛系统数据库设计

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