评论在数据库中存储!!

Posted 2020-08-06 ⬆️小马哥⬆️

而这些不同的动作对应的数据其实是存在不同的表中，例如话题表、回帖表、评论表等等。

今天主要是介绍 OSChina 是如何将这些属于不同范围的数据汇总到用单一时间轴进行展示的动态。

动态表

首先要说明的是动态表，这个表在 OSChina 数据库中对应的表名是 osc_opt_logs ，从这个名字能看出意思是“操作记录表”，字段如下：

字段说明：

id 主键字段，动态记录的唯一标识
user 某人的动态
obj_type/obj_id 由这两个字段组合起来，表示对应不同类型的动作，例如是新闻、提问、回帖等，每一种动作都有唯一的 obj_type 对应，这些常量有：
parent_type/parent_id 这两个字段用来表示具有一些层次关系的动态，例如回帖：parent_type 和 parent_id 就会填充上回帖对应帖子的编号和类型
shown 转发标识，主要用于动弹的评论是否在空间中显示与否
reply_count 如果此动态是一条动弹，那么此字段存放动弹的评论次数
memo 如果此动态是一条动弹，那么此字段存放动弹的内容
attachment 动弹对应的图片
referer 保留用
appid 动弹的方式，可以是PC浏览器、手机版或者不同的手机客户端
create_time 动作发生的时间

obj_type 取值常量表：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public final static byte TYPE_PROJECT = 0x01; public final static byte TYPE_QUESTION = 0x02;  //问题 public final static byte TYPE_ANSWER = 0x11;        //答案 public final static byte TYPE_BLOG = 0x03; public final static byte TYPE_NEWS = 0x04; public final static byte TYPE_CODE = 0x05;   public final static byte TYPE_JOB = 0x06;//招聘职位 public final static byte TYPE_GROUP_BUY = 0x0F; //团购信息   public final static byte TYPE_NEWS_COMMENT  = 0x10; //新闻评论 public final static byte TYPE_BLOG_COMMENT  = 0x12; //博客评论 public final static byte TYPE_CODE_COMMENT  = 0x13; //代码评论 public final static byte TYPE_JOB_COMMENT   = 0x14; //招聘职位评论   public final static byte TYPE_TWEET = 100;//动弹 public final static byte TYPE_TWEET_REPLY = 101;//动弹评论

假设某个动态是回帖，那么 obj_type 值为 TYPE_ANSWER，而 obj_id 的值则为对应回帖的唯一编号。

动弹和动弹评论

动弹和动弹评论是比较特殊的动态，它没有对应到其他表中的关系。动弹对应的 obj_type 值为 TYPE_TWEET，动弹评论对应的 obj_type 值为 TYPE_TWEET_REPLY。而 memo 则存放了动弹或者评论的内容。

当我们进入某个用户空间的时候，会列出这个用户的所有动态，查询很简单：

?

1	SELECT * FROM osc_opt_logs WHERE user = ? ORDER BY id DESC

如果是查看某个类别的动态，例如我们只想看 蟋蟀哥哥 的动弹，只需要：

?

1	SELECT * FROM osc_opt_logs WHERE user = ? AND obj_type = 100 ORDER BY id DESC

其中 100 就是 TYPE_TWEET 常量值。

这样简单的查询，在任何数据库上执行都是非常之快的。

唯一麻烦的在于，取出了动态列表后，如何加载它们对应的目标数据，如果是一个提问，那必须取出对应的帖子记录。

这个的确是很麻烦，代码量也比较大，只能简单的介绍一下思路：

首先将获取的动态列表按照 obj_type 进行分组，然后根据 obj_id 批量去 load 对应的数据，例如我们可组合从像下面这样的 SQL 语句来 load 数据：

?

1	SELECT * FROM osc_questions WHERE id IN (?,?,?,?,?,?)

这样在首次进入某个用户空间，光是动态这块可能需要执行七八个SQL语句来获取显示完整的动态列表，好在这些 SQL 语句都是最基本的查询，再结合缓存的使用，性能还是非常之好的。

查看自己的空间

以上都是关于看别人空间时的说明，但大家应该都发现了，在看自己的空间时，并不只是自己的动态，还会包含自己所关注的人的所有动态。

我自己的以及我关注的人的动态。这个查询条件看似简单，一般人会这样写 SQL 语句：

?

1	SELECT l.* FROM osc_opt_logs l,osc_friends f WHERE l.user = ? OR (l.user=f.friend AND f.user = ?) ORDER BY l.id DESC

请注意这里用到了 OR 查询，这个 OR 查询让你的所有优化都白做，索引也用不上。在你绞尽脑汁研究怎么改 SQL 语句的时候，不妨换一个角度来思考。

不就是差一个我自己的 id 吗？如果在 osc_friends 表里也有我自己的记录，那这个 SQL 不就可以简化为：

?

1	SELECT l.* FROM osc_opt_logs l,osc_friends f WHERE l.user=f.friend AND f.user = ? ORDER BY l.id DESC

这里没有 OR 查询，查询速度快多了。唯一需要处理的就是每次用户注册的时候往 osc_friends 表中插入一条自己是自己好友的记录，也就是 user=我的用户id，friend=我的用户id。

这还是我的偏好，通过冗余数据来提升查询性能。是好是坏，大家自己掂量。

我只能说目前这种方案是适合 OSChina 目前的状态，如果规模再大一点时候肯定还有改造，至于怎么改，到时候再说。涉及到用户动态的其他方面的都不值一提。

全文完，希望对大家有所帮助。

 

 

最近在做类似的功能，遇到几个问题：
1. 动态类型多样性;
2. 数据模块化存储，各模块间通过rest调用数据，造成拉取动态列表响应时间变长;
3. 数据层级复杂，编码逻辑通用性差。例如：转发一篇文章后，评论该转发，然后回复该评论时的对象层级为: 回复->评论->文章。

求有相关经验者分享一下经验为谢！

以下是现有的设计:

动态的结构：

 {
      user_id: 动态创建者ID,
      action: 行为类型,
      object_type: 动态对象类型,
      object_id: 对象ID,
      object_user: 对象所有者,
      view_count: 0,
      created_at: 创建时间,
      deleted_at: 删除时间,
 }

场景列表：

// A 发布 了 文章 xxx 
‘action‘      => NEW,
‘user_id‘     => A的ID,
‘object_id‘   => 文章ID,
‘object_user‘ => A的ID,
‘object_type‘ => ARTICLE,
‘ext‘         => [], 

// A 发布 了 N张 图片 
‘action‘      => NEW,
‘user_id‘     => A的ID,
‘object_id‘   => 图片ID（数组，以逗号隔开）,
‘object_user‘ => A的ID,
‘object_type‘ => PICTURE,
‘ext‘         => [], 

// 4. A 提了 问题 xxxx
‘action‘      => NEW,
‘user_id‘     => A的ID,
‘object_id‘   => 问题ID,
‘object_user‘ => A的ID,
‘object_type‘ => QUESTION,
‘ext‘         => [], 

// 5. A 在 文章 中回复了 B 的 评论
‘action‘      => REPLY,
‘user_id‘     => A的ID,
‘object_id‘   => 评论ID,
‘object_user‘ => B的ID,
‘object_type‘ => COMMENT,
‘ext‘ => [
    ‘text‘ => $text,
    ‘comment_target_id‘   => ‘文章ID‘, //评论所属对象
    ‘comment_target_type‘ => ‘ARTICLE‘,//评论所属对象类型
    ‘reply_id‘ => 回复ID,
],  

// 6. A 评论 了 B的 文章 xxxx
‘action‘      => COMMENT,
‘user_id‘     => A的ID,
‘object_id‘   => 文章ID,
‘object_user‘ => B的ID,
‘object_type‘ => ‘ARTICLE‘,
‘ext‘ => [
    ‘comment_id‘ => ‘评论ID‘,
],  

// 7. A 回答 了 B 的 提问 xxx
‘action‘      => RESPOND,
‘user_id‘     => A的ID,
‘object_id‘   => 问题ID,
‘object_user‘ => B的ID,
‘object_type‘ => QUESTION,
‘ext‘ => [
    ‘answer_id‘ => ‘答案ID‘,
],  

最终我参考开源中国做了调整，以完成我们的需求：

动态的结构：

 {
      user_id:13,
      action: 行为,

      object_id: 对象ID,
      object_type: 对象类型,
      object_user_id: 对象用户ID,

      parent_object_id: 对象父级ID,
      parent_object_type: 对象父级类型,
      parent_object_user_id: 对象父级用户ID,

      reply_id: 回复ID,    // action为回复时有用
      parent_reply_id: 回复的父级回复ID,       // action为回复时有用，回复了别人对评论的回复
      text: ‘转发或者分享时附加文字‘,

      view_count: 0,

      created_at: 创建时间,
      deleted_at: 删除时间,
 }

说明：
1. object_* 只存储主要模块内容信息，不含评论；
2. parent_object_* 存储有嵌套关系的对象，比如当object_* 为答案时，parent_object_*为问题；
3. reply_id 用于直接回复评论时用到；
4. parent_reply_id 父回复ID;
5. 两个回复ID，使用情况是：当回复了别人的回复时，根据comment_id拉取评论与全部回复，在模板显示时只显示对话的两个回复。

场景列表：

一级结构：

• 安正超 发布 了 文章

‘action‘         => NEW,
‘user_id‘        => 安正超ID,

‘object_id‘      => 文章ID,
‘object_user_id‘ => 安正超ID,
‘object_type‘    => ARTICLE,

• 安正超 上传 了 N张 图片

‘action‘         => NEW,
‘user_id‘        => 安正超ID,

‘object_id‘      => 图片ID（数组，以逗号隔开）,
‘object_user_id‘ => 安正超ID,
‘object_type‘    => PICTURE,

• 安正超 提了 问题 xxxx

‘action‘         => NEW,
‘user_id‘        => 安正超ID,

‘object_id‘      => 问题ID,
‘object_user_id‘ => 安正超ID,
‘object_type‘    => QUESTION

二级结构：

• 安正超 评论 了 文章 xxxx（回答了通用）

展示：
  文章： xxxxx
      评论：xxxxx (李林评论的)

‘action‘         => COMMENT,
‘user_id‘        => 安正超ID,

‘object_id‘      => 评论ID,
‘object_type‘    => COMMENT,
‘object_user_id‘ => 安正超ID

‘parent_object_id‘      => 文章ID,
‘parent_object_user_id‘ => 作者ID
‘parent_object_type‘    => ARTICLE,

三级结构：

• 安正超 在 文章 中 回复 了 李林 的 评论

展示：

  文章： xxxxx
      评论：xxxxx (李林评论的)
          回复:xxxx (安正超)

‘action‘         => REPLY,
‘user_id‘        => 安正超ID,

‘object_id‘      => 评论ID,
‘object_type‘    => COMMENT,
‘object_user_id‘ => 李林ID

‘parent_object_id‘      => 文章ID,
‘parent_object_user_id‘ => 作者ID
‘parent_object_type‘    => ARTICLE,

‘reply_id‘       => 安正超的回复ID

四级结构：

• 安正超 回复了 李文凯 在 问题 “xxxx” 中 李林 的答案 下的 评论

说明：问题信息从答案接口取回

展示：

  问题： xxxxx
     答案1...
     答案2...
     答案3...(李林回答的)
        评论：xxxxx (李文凯评论的)
            回复:xxxx (安正超)

‘action‘         => RESPOND,
‘user_id‘        => 安正超ID,

‘object_id‘      => 评论ID,
‘object_type‘    => COMMENT,
‘object_user_id‘ => 李文凯的ID

‘parent_object_id‘      => 答案ID,
‘parent_object_type‘    => ANSWER,
‘parent_object_user_id‘ => 李林ID

‘reply_id‘       => 安正超的回复ID

• 安正超 回复了 李文凯 在 问题 “xxxx” 中 李林 的答案 下的 回复

说明：问题信息从答案接口取回

展示：

  问题： xxxxx
     答案1...
     答案2...
     答案3...(李林回答的)
        评论：xxxxx (A评论的)
            李文凯 回复 A:xxxx
            安正超 回复 李文凯:xxxx

 

‘action‘         => RESPOND,
‘user_id‘        => 安正超ID,

‘object_id‘      => 评论ID,
‘object_type‘    => COMMENT,
‘object_user_id‘ => A的ID

‘parent_object_id‘      =>  答案ID,
‘parent_object_type‘    =>  QUESTION,
‘parent_object_user_id‘ =>  李林ID,

// 以下两个回复只在模板中用到用以决定显示哪两个回复，因为根据comment_id带着回复会全部拉回来

‘parent_reply_id‘ => 李文凯的回复ID,
‘reply_id‘        => 安正超的回复ID,