SNS用户关系表设计，最后的决议。

文献：http://www.verydemo.com/demo_c155_i10331.html

SNS用户关系表设计，最后的决定。。。
到底应该设计成什么样子的，两种方式一对多和一对一。
一对多的话，每一对好友都对应一条记录，这样数据会出现爆炸性增长，一对多的话，一个用户对应一条记录，好友用存储结构存储在一个字段中，但是但需要用到用户好友的反向查询的一些功能时非常不好处理。

到底应该怎么办啊…………
人人网，非死不可到底是怎么设计的哇。

大侠们顺便把水平切分和垂直切分也说一下吧。

PS：即将做的这个服务的潜在用户量非常之巨大……每个人都有可能会用到的。
------解决方案--------------------------------------------------------

引用:

到底应该设计成什么样子的，两种方式一对多和一对一。
一对多的话，每一对好友都对应一条记录，这样数据会出现爆炸性增长，一对多的话，一个用户对应一条记录，好友用存储结构存储在一个字段中，但是但需要用到用户好友的反向查询的一些功能时非常不好处理。

到底应该怎么办啊…………
人人网，非死不可到底是怎么设计的哇。

大侠们顺便把水平切分和垂直切分也说一下吧。

PS：即将做的这个服务的潜在……

照你说的那个怕数据量大，那就最好一对多了，至于查询还是比较好处理的
------解决方案--------------------------------------------------------
每个方法都有优点和缺点，首先要根据客户需求，然后再来谈最优解决方案，任何最优解决方案都需要建立在满足客户需求的基础上的
------解决方案--------------------------------------------------------
不仅如此，还要区分谁是发起方吧
------解决方案--------------------------------------------------------
应该不是关系型数据库吧- -
而且这属于重大商业机密吧...
------解决方案-----------------…………………………………………………………………………