電銷是什麼？就是坐席拿著電話給客戶打電話嗎？no no no，讓我們一起走進京音平臺之電銷系統。 京音平臺2020年初開始建設，過去的兩年多的時間里，經歷了跌宕起伏，有經驗、有教訓，整體來說平臺經歷了人工、自動化階段，目前處於初步智能化階段，希望可以將過去的一些心路歷程分享給大家，共同交流、共同進... ...
背景
又很久沒更新了，很幸運地新冠引發了嚴重的上呼吸道感染，大家羊過後註意休息和防護
工作中（尤其是傳統項目中）經常遇到這種需要，就是樹形結構的查詢（多級查詢），常見的場景有：組織架構（用戶部門）查詢 和 多級菜單查詢
比如，菜單分為三級，一級菜單、二級菜單、三級菜單，要求用戶按樹形結構把各級菜單查詢出來。如下圖所示
對於層級固定，層級數少的，一般3級，需求實現很簡單，先查詢最小子級，再依次查詢上級，最後再組裝返回給前端就是了。
那麼問題來了，如果層級數很大，10級，或者乾脆層級不確定，有的3級，有的5級，有的8級，與之前的層級固定，層級數相比，顯然問題更複雜了，我們來看看這種怎麼處理
三級查詢（層級固定，層級數少）
這種情況，我們只需要一張表，就叫它樹形表吧：
CREATE TABLE tree (
id int not null auto_increment,
name varchar(50) not null comment '名稱',
parent_id int not null default 0 comment '父級id',
level int not null default 1 comment '層級，從1開始',
created datetime,
modified datetime
);
三級查詢過程：查詢出三級tree, 根據三級tree的 parent_id 查詢出二級tree, 同樣的方式再去查詢出一級tree, 後端組裝成樹狀數據，返回給前端。
多級查詢（層級不固定/層級很深）
這種情況，我們首先想到的就是子查詢或者聯表查詢，但是肯本不能在實際開發中使用，原因大家都知道：
- sql語句複雜，容易出錯
- 性能問題，可能會被領導乾
所以最好的方式就是，加一張表 tree_depth，來維護層級深度關係。
CREATE TABLE tree_depth (
id int not null auto_increment,
root_id int not null default 0 comment '根節點（祖先節點）id',
tree_id int not null default 0 comment '當前節點id',
depth int not null default 0 comment '深度（當前節點 tree_id 到 根節點 root_id 的深度）',
created datetime
);
表中 depth 欄位表示的是： 當前節點 tree_id 到 根節點 root_id 的深度，不是當前節點所在整個分支的深度，所有節點相對於自身的深度都是0
有了 tree_depth 表後，查詢一個N級節點的組織數據就方便了：
遍歷整個樹：
直接查 tree 中所有 level = 1 的節點，在出去這些節點的 id 根據 parent_id 去查下級節點， 查詢完所有的節點，就可以組裝成一個完整的樹狀圖返回給前端
節點搜索（查找出這個節點所在的整個分支）
- 從 tree 表查詢出節點 treeN
select * from tree where id = N - 根據 treeN 的 id 值，到 tree_depth 表查詢出它的 根節點id：
select root_id from tree_depth where tree_id = #{treeId} - 根據 root_id 查詢 tree_depth 的 所有當前節點分支數據
select * from tree_depth where root_id = #{rootId} - 從查詢出 tree_depth 表數據中取出所有當前節點 tree_id
select * from tree where id in (?,?,?) - 組裝所在分支樹狀結構
總結
- 多級查詢、三級查詢本質就是樹形結構的遍歷，推薦使用多級查詢的方式，相比三級查詢多級查詢的方式抓住了樹形結構遍歷的本質，方便擴展和維護。
- 技術只是工具，多級查詢的方式不是固定的，查詢方式合理既可，但通常都需要加關係表輔助設計
