前面兩篇文章，分別介紹了使用遞歸和非遞歸算法加載樹形結構數據的方式，本篇文章，則是自己閑下來的時候，進行的一點小思考。
一、什么地方會用到樹形結構
剛開始一看到這種結構的時候，最先是想到了家譜。家譜就是一種樹形結構，那是一種對我來說最為直觀的一種理解。然后，在程序開發中，發現，樹形結構的應用，更多的是出現在一些后台管理系統。而其具體應用，則是作為類似於windows文件夾的一個菜單導航作用。
而，最近在做的一個項目中，在加載某一產品的類別時，也用到了樹形結構。比如說：
生活類
--------A
--------------a
--------B
辦公類
--------A
--------B
但就其主要的應用場景，在我目前接觸到的項目中，還是后台管理系統統居多。一般，作為后台的管理系統來說，對於性能的要求相對來說沒有web端高。其次，一個比較合理的程序設計，一棵樹的設計，不會超過太多的分支，比如說，生活類下面，不能超過10個。總體來說，整個菜單項，控制在50—100個左右，是比較多的。而一個類別的深度，也最多是在4-5度左右。個人感覺，如果超過了4-5度，這個程序的設計必須再靠機會考究。（PS：4-5度，已經是我個人的極限了）
二、加載樹形結構的幾種方式
1，使用遞歸一次性全部加載
2，使用循環一次性全部加載
3，按需加載（使用到那個，再加載哪個。有些目錄，它可能是用不到的，加載出來干嘛。但是，這樣的話，無疑又增加了數據庫的IO操作）
分析：
前提：用戶很少說一次會把每個節點目錄的東西都點一遍，它只會挑選為數不多的幾個菜單項進行操作。而根據遺傳算法的基本思想（用戶上次選擇了哪些菜單項，她下次還有可能會選擇哪些菜單項，靠，我感覺說是程序的局部性原理會更切合實際一點。勿噴，個人聯想），或者說是CPU 如果說數據比較少的話，那么使用第二種方法，我認為還是比較合理的。但如果數據多的話，或許使用第三種才是更合適的。
附：科普程序的局部性原理（往簡單了說，內存的高速緩存區據說就是根據這個原理來的）
空間局部性；
如果一個用戶在本次訪問了2號區域數據，比如說上圖的生活類 A，那么挨着這個2號區域的周邊數據，很有可能會被這個用戶下次訪問。
時間局部性：
如果一個程序，這次執行了指令，比如說執行了查詢用戶的select語句，那么，這條語句，很有可能在不久后，再次被使用執行。
三、個人總結
其實，我個人感覺，在程序開發中，局部性原理還是存在的。比如說一些大型的網站利用爬蟲爬到的數據，分析一個用戶的消費偏好等，這不就是這個用戶總是買生活用品，他下次還有可能買生活用品的東東嘛。所以，或許可以做緩存，或者說，靜態樹形結構（對於一些比較穩定的，我感覺是絕對可以的，而對於一些有先后關系的數據，那么之前的幾種，也可以考慮做一下緩存）
還有，在實際的應用中，我們通常會將整個樹形結構的節點數據保存起來，但通常，用戶真正要獲得的數據，只是在最后一層，才是相對來說真正有意義的。那么，或許我們可以直接將大體上的菜單項寫進緩存，或者寫進程序（因為它沒有實際意義，通常很穩定）比如說：
用戶管理
----------A
---------------a
----------B
報表控制
---------A報表
---------B報表