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

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

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

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

------解决方案--------------------

探讨

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

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

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

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

------解决方案--------------------
每个方法都有优点和缺点，首先要根据客户需求，然后再来谈最优解决方案，任何最优解决方案都需要建立在满足客户需求的基础上的
------解决方案--------------------
不仅如此，还要区分谁是发起方吧
------解决方案--------------------
应该不是关系型数据库吧- -
而且这属于重大商业机密吧...
------解决方案--------------------

探讨

引用:

不仅如此，还要区分谁是发起方吧

如果是一对多的话，用双主键是可以的，也可以区分谁是发起方。但是不需要区分单双向好友，只有一种互为好友关系。

------解决方案--------------------
分区表，几亿条记录是没问题的
------解决方案--------------------

探讨

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

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

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

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