SNS用户关系表设计,最后的决定。。。
到底应该设计成什么样子的,两种方式一对多和一对一。
一对多的话,每一对好友都对应一条记录,这样数据会出现爆炸性增长,一对多的话,一个用户对应一条记录,好友用存储结构存储在一个字段中,但是但需要用到用户好友的反向查询的一些功能时非常不好处理。
到底应该怎么办啊…………
人人网,非死不可到底是怎么设计的哇。
大侠们顺便把水平切分和垂直切分也说一下吧。
PS:即将做的这个服务的潜在用户量非常之巨大……每个人都有可能会用到的。
------解决方案--------------------
照你说的那个怕数据量大,那就最好一对多了,至于查询还是比较好处理的
------解决方案--------------------每个方法都有优点和缺点,首先要根据客户需求,然后再来谈最优解决方案,任何最优解决方案都需要建立在满足客户需求的基础上的
------解决方案--------------------不仅如此,还要区分谁是发起方吧
------解决方案--------------------应该不是关系型数据库吧- -
而且这属于重大商业机密吧...
------解决方案--------------------
A加B为好友
B把A屏蔽了
A加B为好友
A把B屏蔽了
这2种情况能区分,就行了
------解决方案--------------------分区表,几亿条记录是没问题的
------解决方案--------------------
1.设置为一一对应.
2.不用sql server,改用oracle.