sns的 关注 和粉丝 怎么保存比较好

yak 发布于 2012/04/05 10:43
阅读 607
收藏 0
方案1
 uid   follow_uid
 1     2
 1     3
 1     4
 
方案2

uid   focus_uid

2      1
3      1
4      1



方案3

uid    fans
1      2,3,4,5

2     2,3,4

加载中
0
fzxu_05
fzxu_05

3方案 粉丝很多的时候fans很大,

要删除一个粉丝的时候怎么办,效率太低

 

1靠谱

0
yak
yak
摇程1万个粉丝,这样的人多了表是不是就填满了
0
yak
yak
上新浪看了一下 ,  摇程是 18916210
0
匿名t3a
匿名t3a
方案1  就算有几亿条数据 只有两个字段 数据库不会很大 在加上缓存
0
十一文
十一文

建议方案3

 

因为你的fans不可能做查询

同时 如果觉得数据很大,其实可以做压缩的。如果有像要成这么多的那么对于超过一个text字段的可以再分出一个别的表存。对于,用户翻fans到后面多少页的情况,可以说是非常少的。

同时对fans做缓存。

0
leo108
leo108

引用来自“十一文”的答案

建议方案3

 

因为你的fans不可能做查询

同时 如果觉得数据很大,其实可以做压缩的。如果有像要成这么多的那么对于超过一个text字段的可以再分出一个别的表存。对于,用户翻fans到后面多少页的情况,可以说是非常少的。

同时对fans做缓存。

我觉得第一个毙掉的就是方案3,在关系型数据库中,连第一范式都不能满足。

leo108
leo108
@十一文 : 很明显方案3的效率没有1、2好,理由楼下已经说了
十一文
十一文
互联网应用 要高效率就没得必要遵循范式了。这就是这些年在开始提倡nosql的原因
0
fzxu_05
fzxu_05

引用来自“十一文”的答案

建议方案3

 

因为你的fans不可能做查询

同时 如果觉得数据很大,其实可以做压缩的。如果有像要成这么多的那么对于超过一个text字段的可以再分出一个别的表存。对于,用户翻fans到后面多少页的情况,可以说是非常少的。

同时对fans做缓存。

神人! 我现在有100w个粉丝,然后某个粉丝取消关注了,就这一点算算开销吧
十一文
十一文
汗 这个我没考虑到,要达到这个效果只能用1或者2的方式。悲剧 3这种的确是个sb想法 悲剧了
leo108
leo108
@十一文 : 就算fans不准,那在用户界面已经是取消关注了,敢问这里是怎么实现的呢?异步达不到这个效果吧。
十一文
十一文
做异步就可以了。你看看新浪微薄的fans数是不准的,就知道了
0
雷志伟
雷志伟
新浪用的是 Redis,
OSC用的是 MySQL.
0
王振威
王振威
1好吧,类似于好友关系,不过是单向的
返回顶部
顶部