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