一、問題產生

有小伙伴微信私信我，說老板想設計一套三級返傭的微信淘寶客裂變系統，然后問我怎么搞…

咳咳，對于三級分銷的數據庫設計，相信很多小伙伴頭疼的可能不是設計上，而是查詢上，因為通常涉及到會員分級，那么涉及到的查詢可能有且不局限于：一二級用戶列表混合查詢、統計今日注冊一二級用戶、統計本月注冊一二級用戶，如果涉及到了金額，那么可能還會有：查詢一二級充值訂單、查詢一二級充值返傭金額等等等等。

首先我們來想一下，對于這種有上下級關系的表如何設計呢？

通常部門樹是不是符合這個邏輯呢？我曹還別說，上下級部門表還真有那么點意思，我們來看一下這個表結構：

dept_iddemp_namedept_parent_id

部門id	部門名稱	父級(上級)部門id

我們就按這個部門表的設計套進用戶表看看：

user_id（用戶id）user_name（用戶名稱）user_parent_id（父級用戶id）

1	小明	0（假設小明就是一級）
2	小紅	1
3	小王	2
4	小劉	3
5	小張	4

現在的用戶數據等級關系為：（ > 表示推薦）

小明 > 小紅 > 小王

小王 > 小劉 > 小張

如果我想查詢 小明 的二三級用戶，那么就需要通過sql語句：

select * from user where user.user_parent_id = '1' ...

不對不對，這樣查詢出來查到的是 小明 的二級用戶，想要查詢三級用戶的話，就需要用到子查詢了，那么對于這種情況在部門表是怎么解決的呢？

遞歸調用… 是的，遞歸調用，因為本身部門表的數據肯定是有限的，所以用這種方式查詢再加上緩存技術，這點查詢性能問題是完全可以忽略的了，但是用戶表如果這么設計就可以辭職回家了，怎么辦呢？

然后在接下來的討論過程中，小伙伴就說，怎么不給用戶表加一個等級標識呀，就是再加一個字段，比如 小紅 是 小明 的二級，那么這個這個字段就標記為2，小王 是 小明 的三級，那么就標記為3，這樣查詢不就好查詢了嗎。

還別說，聽上去感覺可以，但是，如上數據 小王 是 小明 的三級，但是 小王 同樣也是 小張 的一級，那么怎么標呢？

所以最終的問題就是，使用部門樹這種情況，區分或者查詢二三級用戶比較困難。

二、嘗試解決

其實后來小伙伴們提到的增加等級標識已經有那點意思了~

我們接下來將這個User表跟這個等級標識進行拆分一下：

用戶表（user）：

user_iduser_nameuser_parent_id

用戶id	用戶名稱	父級用戶id

用戶關系表（user_relation）：

iduser_parent_iduser_children_iduser_level

關系表主鍵	父級用戶id	子級用戶id	用戶等級

簡單說明一下用戶關系表的主鍵，設計上實際沒什么作用，但是仍加上這個自增主鍵是因為，對于InnoDB存儲引擎來說，如果當前表沒有主鍵，那么會默認生成一個隱藏列作為自增主鍵，所以怎么都是生成主鍵，還不如自己指定一個主鍵，顯式主鍵可以提高查詢效率。（面試小技巧，Get到了嗎）

通過如上兩個表我們就可以很簡單的區分上下級關系了，我們套入上邊的數據看一下：

小明 > 小紅 > 小王

小王 > 小劉 > 小張

iduser_parent_iduser_children_iduser_level

1	1（小明）	2（小紅）	1（一級）
2	1（小明）	3（小王）	2（二級）
3	2（小紅）	3（小王）	1（一級）
4	3（小王）	4（小劉）	1（一級）
5	3（小王）	5（小張）	2（二級）
6	4（小劉）	5（小張）	1（一級）

通過這種模式，是不是就清晰多了呢，感覺能分好多級啊，如果你想弄個四級分銷，咳咳，親，我這邊建議您趕緊離職（國家規定超過三級就算違法）。

三、關系總結

最近有不少小伙伴微信私信我，關于這篇文章可能描述的并不清晰，所以臨時補充一下節點三。

上邊的表格數據實際只是到2級，并沒有涉及3級，但是思路是一樣的。

三級分銷涉及到的其實是4個人，我們就以三級分銷舉個例子。

ABCD，A > B > C > D（箭頭代表推廣分銷關系），D 消費后，C 拿一級代理返傭金額，B 拿二級代理返傭金額，A 拿三級返傭金額，如果 A 上面再有人，就不算了，因為這是三級營銷，不然就成了四級營銷。

有的小伙伴看到這，也覺得關系是捋順了，但是代碼不知道怎么寫了？

其實這個關系表是在用戶注冊時產生的，且核心也是以新插入數據為基點，向上找。

我們還是以 D 為例，D 注冊后，會通過推薦碼找到自己的上級 C，如果 C 再有上級那么就找到 B，B如果還有上級再找到 A，A 再往上就不找了，因為是三級分銷。

其實落實到表中數據就是：

iduser_parent_iduser_children_iduser_level

1	C	D	1（一級）
2	B	D	2（二級）
3	A	D	3（三級）

其實濾清這個關系，主要是以新增結點往上找，在代碼中就很好體現了，比如 D 注冊時通過推薦碼找到C，然后 C 再通過用戶表的 parent_id 字段找到 B，依次類推找到 A，至于返傭的金額及規則就不闡述了，大家可以根據自己情況設置。

四、相關查詢

那么我們現在再來看看數據的查詢：

一級下級查詢：（小明的一級用戶為例）

select * from user_relation t where t.user_parent_id = '1' and user_level = '1'

二級用戶查詢：（小明的二級用戶查詢）

select * from user_relation t where t.user_parent_id = '1' and user_level = '2'

一二級用戶列表混合查詢：（小明的一二級用戶查詢）

select * from user_relation t where t.user_parent_id = '1'

對于當前用戶查詢時 user_id 肯定是明確的了，大家可以自行關聯 user 用戶表詳細信息

統計今日注冊的一級用戶：（小明的一級用戶為例）

select count(id) from user_relation relation where t.user_parent_id = '1' and user_level = '1' and relation.create_time = curdate()「mysql日期函數」

統計今日注冊的二級用戶：（小明的二級用戶為例）

select count(id) from user_relation relation where t.user_parent_id = '1' and user_level = '2' and relation.create_time = curdate()「mysql日期函數」

如果涉及到金額，或者訂單呢？

先上訂單表(精簡版)：（user_orders）

order_id（訂單id）user_id（用戶id）amount（消費金額）

1	2（小紅）	5元
2	3（小王）	3元
3	3（小王）	4元
…	…	…

查詢小明一二級用戶訂單返傭金額（假設一級用戶返傭10%，二級用戶返傭5%）：

SELECTsum(decode(relation.user_level,1,orders.amount*0.1,2,orders.amount*0.05) ) AS rebate_amount FROMuser_relation relation,user_orders orders WHEREorders.USER_ID = relation.CHILDREN_USER_IDAND relation.user_parent_id = '1'and relation.user_level > 0

好了，到這羅列了幾個一二級的簡單查詢，更多的查詢大家自行根據場景需要編寫。

博客園持續更新，歡迎大家訂閱關注，一起成長。

本文首發于博客園：https://www.cnblogs.com/niceyoo/p/13614975.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的网站三级分销数据库如何设计，简单案例的全部內容，希望文章能夠幫你解決所遇到的問題。

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