Tree 1 樹形結構資料呈現的遞迴演算法實現

在我的專案中，常常會用到樹形結構的資料，最為明顯的就是左邊選單欄，類似於window folder一樣的東西。

而我之前一直是借助前端封裝好的ztree等工具實現展示，而後台則通常使用遞迴進行資料的查詢。通常，我們在設計資料庫表的時候，一般會使用三個字段：id，name，pid。如下圖所示：

首先是建立實體類treeentity：

private string id;

private string name;

private string pid;

編寫實體類的get和set方法。

然後，我們通常會有以下的幾個方法（通常情況，封裝粒度不同，方法的實現個數和內容也不同）：

public listfindallparents() 
} catch (sqlexception e)  finally 
return treelist;
}

public listfindchildbypid(string pid)

} catch (sqlexception e) finally

return treelist;

}備註：這兩個方法可以合併，這裡是為了讓自己更好的理解，而寫了兩個方法。可以判斷傳入的pid的值，確定其查詢的是父節點，還是根據父節點查詢子節點。

最近，由於考試，看了資料結構這本書。首先，我是在想，大家都用的這種方法，到底好在哪兒了，還有就是，為什麼在我們的資料庫設計中，樹的度的概念沒有體現出來。其次是，對於樹的遍歷，有非遞迴的方式，我想也許，我也可以不用遞迴，就實現樹形結構的資料查詢。於是乎，請看下文：

為什麼我不想用遞迴：

1，經過查證，系統使用遞迴演算法，需要系統堆疊處理。當樹的深度很大時，由於系統支撐不住，會呈現死亡狀態。

2，遞迴演算法的執行效率較低，無論是耗費的計算時間還是占用的儲存空間都比非遞迴演算法要多。

3，最為直接的原因：很長一段時間裡，我都不能理解遞迴演算法，我總在想，可不可以用我會的，我喜歡的方式，去解決我面臨的問題？

遞迴的好處：

結構清晰，可讀性強，而且容易用數學歸納法來證明演算法的正確性，因此它為設計演算法、除錯程式帶來很大方便。

事實證明，對於樹結構的資料搜尋，完全可以不使用遞迴。我總算完成了我自己的夢想，終於，我可以不用遞迴，也可以實現樹結構的查詢了。更為高興的是，事實證明，採用非遞迴的方式，在我接觸到的專案中，它有更大的優勢。