簡單點說二三級分銷系統，
1、用戶通過分享鏈接促成商品賣出，獲取到一定比例的商品利潤。
2、用戶促成交易獲得一定比例的利潤時，其上級用戶也會獲得一定比例的利潤。
對於本人所設計的分銷系統，與二三級分銷系統還是有很大的差別，
只要是上級用戶，其下級或無線下級的用戶一旦獲取利潤，其都可以獲得一定利潤比咧，而類似於微信的二三級分銷系統，是只有連續的三級用戶才可以獲得利潤。
這里只為解決這些需求所帶來的技術難題，不做實際應用。
由上我們可以分析出一些內容
數據庫設計方面：用戶表的設計，用戶的上下級關系如何設計，推廣鏈接的數據庫存儲，用戶與推廣鏈接的數據存儲
網上看到用戶上下級關系有很多存儲方式，
比如，
方法一、
用一個tree字段存儲字符串來表示上下級關系模式，比如A用戶是B用戶的上級，
則用戶B的數據庫中tree為"/A/" , B用戶的下級是C用戶，則C的tree是"/A/B/"
這樣要數據庫查找上下級關系的時候只需要SELECT * FROM user WHERE treelike "/A/%"
如上面sql語句是查找出A的所有下級用戶，使用一條簡單的sql語句即可完成查找。
如果要找到當前用戶的所有上級用戶也是用like關鍵字進行匹配，如查找C用戶上級 , %是通配符，匹配任意多個字符串
SELECT * FROM user WHERE treelike "%/C"
這個查找上下級時間復雜度是O(n)，但是新增一個下級用戶，或刪除下級用戶時，這個操作可能會變了很復雜，要修改所有相關的tree字段
方法二、
還有一種引入左右值數據的方法，也就是增加left和right字段
基於Tree的前序遍歷的無遞歸查詢、無限分組的左右值編碼方法
圖片來源鏈接
https://www.cnblogs.com/huey/archive/2015/05/21/4518979.html
左右值編碼方法還不會使用，只能暫時放棄，看的頭暈怎么破啊
資料來源：https://blog.csdn.net/monkey_d_meng/article/details/6647488
最后本人還是使用相對原始的方法，
方法三、
繼承關系，
設置一個Parent_id的方式進行樹的存儲，
用遞歸的方式進行遍歷某個節點的子孫節點，獲得節點的唯一一條父節點列表。
寫的一個大概得代碼描述，可以借鑒
補充下遍歷下級用戶的方法，但數據返回給前端后有點復雜，要js循環解析json數據
/** * * @param id * @return */ public JSONArray searchSubCustomer(int id) { /** * 這里只查詢用戶下一級的子用戶。 * 有數據情況下，遍歷其子用戶， * 當如果該用戶沒有子用戶，即返回為null時，直接返回null並且結束這個方法，可在for循環中看到邏輯處理 */
// 這部分sql查詢，按照自己的方法數據庫查詢，這個查詢是調用JFinal框架的ActiveRecordPlugin 這個插件進行數據庫查詢 List<Customer> customerList = Customer.dao .find("SELECT * FROM customer WHERE id IN (SELECT id FROM customer WHERE parent_id=?)", id); if (customerList == null) { return null; } JSONArray jsonArray = new JSONArray();//這個用來保存所有的數據集，嵌套使用 for (Customer customer : customerList) { //這個通過傳遞用戶id，進行遞歸查找其所有下級用戶。如果返回null，說明其沒有下級，直接將 //它自己放進jsonArray數據中。 JSONArray temp = searchSubCustomer(customer.getInt("id")); JSONObject jsonObject = new JSONObject(); if (temp == null) { //沒有下級，直接放自己 jsonObject.put("self", customer); jsonArray.add(jsonObject); } else { //有下級，放自己的同時，另起一個subUser為key放所有下級 jsonObject.put("self", customer); jsonObject.put("subUser", temp); jsonArray.add(jsonObject); } } return jsonArray; }
獲得的結果類似於下面結構，如果沒有下級直接返回空，即[ ]
只有一個下級則會返回下級本身，即 [ {self:下級對象} ]
如果下級還有下級，則結構為 [ {self:下級對象自身},subUser:[ 下級集合數組 ] ]
[
{slef:object},
{self:object,
subUser:[
{self:object,
subUser:[]
},
{...}
]
},
{self:object}
]
可能我的數據量比較小，感覺用着速度還是很快了。可能數據量比較大的場景不適合，要使用sql的存儲過程來提高查詢速度。
能用就好吧！
用戶與推廣鏈接的關系，直接使用邏輯上（不加外鍵約束）外鍵連接即可，進行分潤時候，直接使用List存儲父子關系，反向進行分潤即可。
可參考數據庫代碼：