這篇文章是一篇小小的總結(jié)，如有疏漏請指出，萬分感謝。

分銷系統(tǒng)需求

一個分銷系統(tǒng)當中，基本有幾個要點，我以商品二級分銷模型為例子。
1.銷售人員發(fā)展客戶，自己和上級能夠獲得獎勵。
2.當客戶購買產(chǎn)品的時候，銷售人員和上級也能獲得獎勵。
3.發(fā)展用戶或者銷售人員時，需要綁定他們的關(guān)系。
4.銷售人員能夠看自己下級的人員并查看自己的銷售業(yè)績。
That's all.

不堪回首

當時剛接觸這個需求的時候，由于本來用戶表有一個 pid(parent_id) 的字段，來表示自己的上級銷售人員。我當時竟然可怕的是用了 ppid，pppid來表示更上級的人員。。。。。。我的天，居然有人會做出這種事。多么可怕的一段黑歷史。

從文件系統(tǒng)想到分享系統(tǒng)

目前在維護一個有上千億行數(shù)據(jù)的文件系統(tǒng)，分表分8192張。表結(jié)構(gòu)里面有一個字段，專門維護文件夾層級，里面的值遵循一定的數(shù)據(jù)格式，長得很像linux的文件系統(tǒng)層級結(jié)構(gòu)（例如:/usr/bin/local/），可以說是一模一樣。突然，這不就是樹結(jié)構(gòu)嗎？然后想到了分銷系統(tǒng)的樹結(jié)構(gòu)

開干！

用戶表字段設計：user_id，parent_id，tree，level，money
這里涉及到一些家喻戶曉的人，分別是，A，B和Cn
他們有相關(guān)從屬的關(guān)系。
用表來表示：
A進了某養(yǎng)生品公司，注冊了會員。
于是A成為了這個系統(tǒng)的第一個用戶

| user_id| parent_id | tree| level| money|
| ------------- |:-------------:| -----:|
|A|沒有爸爸|/|1|0|

這時A走在大街上，看到B，說：“你聽說過安利嗎? blablabla”
然后B掃碼成為了A的下級會員，A獲得一塊錢的發(fā)展會員獎勵，并告訴他，你可以告訴你的新朋好友哦，賣出這么好的產(chǎn)品，可以分成哦。

于是有了

| user_id| parent_id | tree| level| money|
| ------------- |:-------------:| -----:|
|A|沒有爸爸|/|1|1|
|B|A|/A/|2|0|

那么B開始努力推廣安利這個產(chǎn)品
給認識的熟人（C1，C2，C3）安利了一發(fā)

于是有了

| user_id| parent_id | tree| level| money|
| ------------- |:-------------:| -----:|
|A|沒有爸爸|/|1|4(1+3)|
|B|A|/A/|2|3(0+3)|
|C1|B|/A/B/|3|0|
|C2|B|/A/B/|3|0|
|C3|B|/A/B/|3|0|

很明顯了

這個表設計的優(yōu)點
1.可以通過 tree 很快的找到 C1 用戶的所有上級用戶進行相關(guān)操作
2.可以通過 like tree 操作，利用索引，查詢 A 用戶所有的下級進行相關(guān)計數(shù)操作，可以提高 A 的推廣積極性
3.通過用 tree 屬性去關(guān)聯(lián)訂單表，給上級返利或者查詢自己的推廣所得，也是很方便。

tree 與 linux 文件系統(tǒng)忒像了

其實這個分銷的樹形結(jié)構(gòu)像極了文件系統(tǒng)的標識符，我也是在做相關(guān)mysql存儲文件關(guān)系的業(yè)務當中類比出如此高效快速的查詢方法。

缺點

這個設計模式的缺點也很明顯，一旦關(guān)系轉(zhuǎn)移(類似文件夾移動)，就會產(chǎn)生大量的tree字段修改。所幸的是：關(guān)系轉(zhuǎn)移可以異步處理，但查詢關(guān)系就必須同步。鑒于這種操作特點，也就可以采取這種模式。