鍍金池/ 問答/數(shù)據(jù)庫/ 用戶推薦關(guān)系表如何設(shè)計比較合理？

用戶推薦關(guān)系表如何設(shè)計比較合理？

維護一個有用戶推薦關(guān)系的項目，用戶間的關(guān)系就是
a推薦b, b推薦c, c---------N,無限級。
設(shè)計表的時候遇到了難題。
這個系統(tǒng)以前實現(xiàn)的方式是mysql單表,只有兩列。

clipboard.png

uid: 用戶id, 主鍵。
datas: 推薦關(guān)系。數(shù)據(jù)格式如 ,0,1,2,3,4,5,6,------n,每個數(shù)字代表一個用戶的id。

clipboard.png

我在想，這種用戶推薦的關(guān)系，查詢起來很麻煩呀，比如：要查找某個人推薦的第幾個人，很難查呀。。。。
想把這個表改成，每推薦一個人一條記錄的方式。

clipboard.png
id:主鍵
parent_id:推薦人的id
uid:被推薦人的id
depp:被推薦人當(dāng)前的深度

clipboard.png

**兩種實現(xiàn)方式，哪個好些？
或者，有沒有更好的實現(xiàn)方式？**

回答
編輯回答
尕筱澄

很明顯，后面一種方式好啊，可以在parent_id和deep加個唯一索引，查找速度就更快了。只不過在新增數(shù)據(jù)的時候，需要額外一些開銷在計算deep上?；蛘吣阋部梢圆灰猟eep列，新增數(shù)據(jù)的時候直接插入，在查找時 WHERE parent_id = 用戶ID ORDER BY ID ASC LIMIT 1,1，這就是用戶第二個推薦的人了。結(jié)合使用場景看怎么取舍了。

2018年8月21日 09:56
編輯回答
胭脂淚

我喜歡兩個一起存 · 以后查詢方便

2017年2月7日 13:51
編輯回答
命多硬

肯定第二種撒，這樣可以了

2017年3月24日 17:28
編輯回答
誮惜顏

這種場景應(yīng)該用nosql啊，例如Neo4j 比較合適

2017年10月15日 05:56