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