OSChina 用户动态设计说明

参考：http://www.oschina.net/question/12_70587?from=20120923

前两天我们分享了 OSChina 的留言表设计说明，今天继续。

用户动态是用户在 OSChina 上做的一些动作，例如提问、回答问题、动弹、评论动弹、发表新闻评论、代码分享、写博客等等一系列的行为。好比说我们进入 @蟋蟀哥哥 的个人空间，就能看到他最近都做了些什么动作:

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

今天主要是介绍 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 取值常量表：

01	public final static byte TYPE_PROJECT = 0x01;

02	public final static byte TYPE_QUESTION = 0x02;  //问题

03	public final static byte TYPE_ANSWER = 0x11;        //答案

04	public final static byte TYPE_BLOG = 0x03;

05	public final static byte TYPE_NEWS = 0x04;

06	public final static byte TYPE_CODE = 0x05;

07

08	public final static byte TYPE_JOB = 0x06;//招聘职位

09	public final static byte TYPE_GROUP_BUY = 0x0F; //团购信息

10

11	public final static byte TYPE_NEWS_COMMENT  = 0x10; //新闻评论

12	public final static byte TYPE_BLOG_COMMENT  = 0x12; //博客评论

13	public final static byte TYPE_CODE_COMMENT  = 0x13; //代码评论

14	public final static byte TYPE_JOB_COMMENT   = 0x14; //招聘职位评论

15

16	public final static byte TYPE_TWEET = 100;//动弹

17	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.friendAND 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 目前的状态，如果规模再大一点时候肯定还有改造，至于怎么改，到时候再说。涉及到用户动态的其他方面的都不值一提。

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