类似QQ空间的社交网站的用户动态的数据库应该怎么设计

动态的结构：

{

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父回复ID5. 两个回复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

针对sql server数据库来说（sql server比mysql好一些，比oracle差），如果有一个万个用户就一万张表。数据库对表数量的支持也是有限制的。

并且创建表需要有相应的级别比较高的权限，如果每注册一个用户就新建一张表，用户的权限太高了。

再次，按照你的说法，一个人假设有1000个好友，每个表也就1000条数据，相对于数据库来说，这个存储量是相当小的，没有发挥到很好的性能。sql server数据库几百万万条数据是没问题的。

最后，这样查询可能会带来方面之处，但是如果用到了存储过程，复杂的联合查询等（这些都是在数据库中常用的），你这样做就很难完成了。

所以，为何不把这些数据集中到一张表里面呢？

---