做过人脉社区或者交通线路图的大虾请进!

最近公司要开发一人脉社区,
其中人脉系统部门需求必要变态了点,

好友分为三种:
一度好友:用户的好友
二度好友:用户好友的好友
三度好友:用户好友的好友的好友

要将这三类好友的数量统计出来,如:

一度好友:10
二度好友:300
三度好友:3500

并在地图上标识每一个好友的地理分布,
然后还有将所有好友进行地区排行 ,
哪位大虾有做过类似的功能,算法上该如何实现?请教啊

确实是个蛮bt的问题,不过可以折衷一下给出解决方法.

因为还要给出每一位好友的地理分布,所以一定要有好友的资料.之前考虑下想说每个人的个人信息里面增加一个自己好友数目的字段,这样查询一个人的好友数目,只需要把它的好友的好友数目加起来就可以了,效率很高.不过这样的设计符合不了下面标识地理位置的功能.所以,只能换个做法.

个人的建议是增加一个中间表

userid friendid
1 2
1 3
1 4
3 1
3 4

1度好友,最简单 通过userid查询
2度好友,需要一点小小的技巧,就是自身表连接,比如说给中间表起2个别名,叫a1,a2,那么查询的条件就是 a1.userid=1 and a1.friendid=a2.userid.关于自身表连接的具体用法,可以自己查找一下sql方面的资料
3度好友,其实就是在2度的基础上再加一层自表连接.逻辑思维上需要再拐个弯.查询条件应该是a1.userid=1 and a1.friendid=a2.userid and a2.friendid=a3.userid :x 我也有点拐不过来..但是其实从数据库设计的角度来说,自身表连接就是跟你所谓的2度,3度这样的连接是对应的,如果还要个4度,那也就是4层的自表连接而已.

这样的查询跟普通的查询在效率上没什么区别,不会有什么性能问题.统计一个人只要3条sql而已.

你还要做在地图上显示地点的,只要用获得的id去取用户数据就行了.如果还要加上什么地区排行,就在中间表再增加一个zoneid来标识地区就可以了.

如果担心在线用户非常多会出现并发效率问题的话,除了索引之类的常规手段之外,其实可以做查询缓存,3度好友数据量比较大,其实变动不会非常频繁,这个数据也没有实时精确的要求,对于3度好友,可以几个小时查询一次,更新一下字段就好了.谁会这么清楚的要求算明白自己的3度好友有多少个呢?