MYSQL 遞歸操做

MYSQL 遞歸？

=====================

表： t_node

node_id int

node_name varchar2(45)

parent_id int

 

select * from t_node;

 

遞歸開始：

1.       向下查詢：查找指定組下的全部分組 ( 不包括自己 )

select t2.node_id ,t2.node_name,t2.parent_id

from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 );

分析：黑色部分爲要查的組 id:0

結果：

2.       向下查詢：查找指定組下的全部分組 ( 包括自己 )

select t2.node_id ,t2.node_name,t2.parent_id

from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 )

union select t3.node_id ,t3.node_name,t3.parent_id from t_node t3 where t3.node_id= 0 ;

分析：黑色部分爲要查的組 id:0

結果：

 

3.       向上查詢：查找該組的全部父組

 

注意：發現一個問題，白馬查不到。

上面的查詢只能查 3 級，

 

轉自：

分類表是一種典型的層次化關係的表，從數據庫設計工做的角度看，讓每一個分類記錄的 parentId 字段指向它們父分類的 Id便可。 
把層次關係轉化爲數據表並不困難，並且層次還相對比較清晰，但在這種表面現象的背後還有許多難題在等待着用戶解決。好比，咱們沒法只用一個簡單的 SELECT 就把指定分類的父分類或者子分類所有查詢出來，而必須經過屢次查詢才能解決這個問題（或者一次查出後，用程序來進行處理）。 
事實上，數據庫設計和 SQL 編程有着千絲萬縷的聯繫，很難將他們徹底區分開來，再者，若是 SQL 不足以把想要查詢的數據從數據表裏提取出來，那麼，想拿出一個優秀的數據爲設計方案就只能是一句空談。 
想要經過數據表去管理和使用層次關係，得解決不少難題，而這些難題幾乎都與 SQL 語言不能遞歸查詢這一事實有關。以分類表爲例： 
1 、只用一個查詢就把指定分類的全部父分類所有查出來是不可能的 
2 、把完整的數據表還原爲層次關係（樹狀）也是一個難點，仍是必須執行屢次 SQL 才能完成。 
3 、把指定分類下全部子分類所有查詢出來 
4 、設計時，一個分類不能有兩個父分類（例如： sql 語言既可以放在 database 分類中，但好象放在 programming 分類下也行，所以，若是 sql 語言有兩個父分類彷彿纔是合理的） 
5 、層次關係最擔憂 的是留下循環引用隱患（好比手工刪除數據或者添加數據時，很容易致使第 4 條的狀況發生，數據庫層次斷鏈或者重複等） 
雖然有這些存在的問題，但並不是不可解決，而從上面這些難點來講，層次關係每每會致使即便是一個相對簡單的問題也須要不少條 SQL 查詢才能得出答案，並且整個過程都至關慢。若是不使用層次關係（或者使用有限的層次關係），上述問題即均可以免。若是必須使用多級的層次關係，增長一些數據列或數據表來提供更多關於層次關係的信息，將有助於層次關係的解決方案變得簡單一些。 
從範式的標準來講，冗餘是不對的，它會致使存儲空間沒必要要的浪費，增長數據庫內部管理工做的負擔，但爲了提升應用程序的執行效率，冗餘反而是一種至關簡明的解決方案，所以，數據庫設計實際上是一件多方妥協和折中的事。在數據庫領域，通往同一個目標的道路每每有好多條，選擇其中的任意一條，都意味着做出了這樣或那樣的妥協。作出什麼樣的妥協最有利這每每取決於數據庫的具體使用狀況：什麼類型的查詢發生的最爲頻繁？數據需不須要頻繁修改？