為什么80%的碼農(nóng)都做不了架構師？>>> ??

我的問題：上星期一直糾結的是怎樣獲取用戶之間人際關系，今天和魯博士討論后發(fā)現(xiàn)用這種策略：

我先講一下我的問題：我要獲取一個event所有參與者和wishers之間的人際關系，原來我一直使用的方法是直接在通過豆瓣API搜索倆個用戶之間關系，但是我的問題是如果一個event的用戶有1000人，豆瓣的API是每次單獨對倆個用戶提取用戶關系，這樣我就需要訪問1000*1000次數(shù)據(jù)庫，這樣做的時間成本過高，需要進2天時間才能獲取一次用戶人際關系；

但是這樣做的好處是我能得到的數(shù)據(jù)結果非常清晰：< 用戶A, 活動參與者，用戶B，活動參與者，Friend>

現(xiàn)在的想法是：我直接對所有參與活動的用戶每一個提取他們的Followers，即他關注的人，得到的是這樣的數(shù)據(jù)庫

A	B
A	C
B	D
B	C
C	D

這樣我們得到所有參與（參加+感興趣）用戶的關注人網(wǎng)絡，而且左側的用戶一定是參與者，那么右側用戶中過濾掉不在參與者中的用戶，這樣得到的用戶就是左右倆邊都在用戶網(wǎng)絡中。如果有A B ,和B A，那么說明用戶AB的關系是好友，否則就是關注而已；

這樣得到用戶的人際關系表為：

A	B
A	C
B	C

但是最終我們期待得到的針對一個event得到的結果為

?event1	A	participants	B	wishers
?event1	B	wishers	C	participants
?event1	C	participants	D	wishers

所以還差一步：用戶的身份，即pariticipants還是wishers。

為什么：因為我想看看人際關系變化與用戶身份的關系；最笨的就是再搜索；

這樣做的好處是因為提取用戶的關注者是很容易的，而且用戶的關注者本身不會太多，所以會比較快速；

解決方法：利用mysql 里面的

update events_beijing_users_ralationship_5_27 set sourceIdType = "participants"?
where sourceId in (select participantsId from events_beijing_participants_5_27)&&
eventId in (select eventId from events_beijing_participants_5_27);

轉載于:https://my.oschina.net/durong/blog/134013

總結

以上是生活随笔為你收集整理的获取用户之间关系——使用followerway的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。