请做架构的朋友一起讨论下SNS中好友动态功能建模的设计

噢，是吗？

愿闻高见。

保证性能的基本就是尽量减少数据库操作，必要的冗余数据是不可避免的

就这个需求来说那就是只做一次多对多的user_firends关联多对一user_operation的查询就能获得所有的信息（更极端的把operation信息放到多对多表中，冗余太多一般不推荐），那就是一个sql搞定了，你打算用dataId来干什么，如果不是摆设就是动态获得操作信息了，相信你对sql对性能的影响有正确的概念，我就不多说了。

上面一次sql所需的参数就是user_id（用于关联）, operation_time（用于排序）, 操作信息operation_raw_data与操作相关，可以有不同的处理，简单就不举例了，复杂的举两个例子
发布了5张照片
username:香浓咖啡
picture_group_id:xxx
picture_number:5
picture_id:[1,2,3,4,5]
与某某加为好友
username:香浓咖啡
new_friends_id:[1,2,3,4,5]
new_friends_name:[企业邮箱,cobain,xxx,yyy,zzz]
这些信息拿到后怎么显示都可以，对应不同模板即可，实现方式可以用java, javascript，css等等，性能差别都不大

模块间接口消息化，异步化，我肯定不会让所有模块都去直接读库的
都要什么字段那是和具体需求相关的事情了。

这个需求关键部分在于展现部分，对记录的持久化的方式不是关键，没有异步的必要

消息和异步是用来解决性能问题的，我假设楼主的网站已经具备了一定的用户数、数据量和访问量，
真要是我自己来搞，先拿个脚本随便写写跑起来再说了，性能优化是很久很久以后的事情

赞同这种写法，毕竟用户活动的数据只是在这里展示下，没有什么业务意义，完全可以用个varchar(2000)来把所有的数据都保存起来

呵呵，和我预料的解释差不多。

首先这是一张动态表，没错把。它的数据是怎么产生的呢？程序在写到数据表的同时另外要写一份到动态表把。那么两者写的速度在sns这样的网站是否越短越好呢？

拿数据前如何判断呢？我同意你观点根据时间，肯定不是根据内容。换句话说如果按照豆瓣的，只需要快速确定10条或者20条数据（满足一页显示就够），那么在动态表中搜索到10条符合的dataid，然后到对应的表格拿相应的数据。
假设数据表有100万条记录，你觉得动态表有100万条么？（因为只显示最新的10条，那么其他过期的数据在显示的时候就可以删除了）
我测试过100条数据直接通过主键拿10条数据相当快，大概30ms(当然这和字段数和内容有关）。

另外程序通常在启动时会将常用的动态表都扔到内存上，越少越好了。

数据表要怎么设计我不知道，如果分开的话，用datatype来分。

一般sns的都不会之瞄准少量用户把，肯定是用户越多信息越多越好。单台数据库自然不能平衡，多台数据库很正常.所以用到nodeid



当然这也可以写shell，直接建立在内存上。

首先，这就是一个普通的表，没有必要动态表
其次，显然你对sql对性能的影响没有正确的概念
再次，而且你认为30ms时间很短，这个我比较寒（而且这个30ms还是理想情况下的小数据量单个请求的响应！）
最后，数据库集群的nodeId不应由你的业务来管理，这个由集群服务器管理

我只能无语了。

1.用户拥有好友的id列表
2.数据库允许通过id直接定位到记录或者数据块（用hash或者定长表，不要用b树索引），保证通过id查询时间最短。
3.每个用户都做近期操作的Log，存到自己id对应的记录或者数据块中。
4.访问某用户的好友近期操作时，直接按照好友id列表取出对应用户的log.
5.对log组成的新表按时间排序...