今天去招聘，問一個來面試的，問的是C#的問題，問到如何計算樹的下級節點。其實我的本意是讓他在設計樹的結構的時候，增加一個FULL_CODE字段，通過SQL的左LIKE進行
查詢。不過小伙子很有意思，我已經提示他多次了，依然義無反顧的一頭扎到算法中，非要用算法進行計算。於是引出了今天的隨筆！
小伙兒覺得應該用遞歸來計算樹的下級節點，我說性能太差，當然，我的本意是讓他用FULL_CODE來進行左LIKE，不過小伙子想了想，說：“那用動態規划吧。”
雖然沒有回答完全正確，但是也算不錯。於是我問到，那么你首選哪個，小伙說是遞歸。於是我就郁悶了，我說前面已經說過了，遞歸性能性能太差。小伙的理由是
雖然動態規划要快一點，但是算法不好寫。綜合考慮之后，還是覺得遞歸比較簡單。我一看，得，人家就認准了遞歸了。於是今天就專門寫了個動態規划和遞歸的算法的時間比較。
遞歸就不在贅述了，說說動態規划吧，其實動態規划很簡單，基本來講就是將上一次的計算結果記下來，記作A，然后這個A參加下一次的計算，以此類推，直到計算結束。我用遞歸和
動態規划實現了斐波納契數列計算，遞歸如果超過40的時候就已經需要很長時間了（C#對於遞歸的開銷比較大），40次大概需要1秒左右，但是用動態規划要一億次，才需要4秒，這個相差
的可不是幾個數量級的問題。
所以，在以后的開發中，盡量避免使用遞歸！