最近看到一篇博客《撸一段 SQL ? 還是撸一段代碼？》，文章舉例說明了一個連表查詢使用程序code來寫可讀性可維護性更好，但是回帖意見不一致，我想作者在理論層面沒有做出更好的論述，而我今天才回帖結果發現不能回帖了，於是單獨寫此文隨記。
連表查詢的確應該盡量避免，雖然普通情況下一條連表查詢的SQL效率比兩個for循環效率更高，但是我們應該知道大量依靠復雜SQL查詢的應用程序，數據庫很容易成為瓶頸，但應用程序所在的服務器卻比較空閒，那麼此時應用程序表現的結果就是等待數據庫返回查詢結果，總體時間更長了，這也是“木桶定律”在軟件中的體現，因此，正確之道是要使得系統各個節點不要出現短板，在不使用連表查詢的情況下，我們可以將表分散到不同的數據庫，實現分庫分表，並結合並行查詢，總體上提高系統資源利用率，提高程序執行效率。
當然，上面的結論也有前提，就是每次查詢的網絡IO不能成為瓶頸，否則還是在數據庫中執行連接操作比較合適，如果有密集的查詢並且每次涉及大量IO，這種情況下甚至應該使用存儲過程，所以到底是應該寫在code中還是寫SQL，應該具體問題具體分析。
根據絕大部分項目實際情況，80%的查詢都是一些簡單的單表查詢和連表查詢，這部分查詢用ORM是很合適的，結合緩存的確能夠很大程度上提升系統效率；而剩下的20%查詢涉及復雜的SQL和大量的IO，此時應該直接使用SQL或者存儲過程，所以一個項目我們選擇數據層框架的時候，需要它既支持ORM，也支持SQL，但應該是高級別的支持SQL，集中管理或者配置SQL的形式，類似iBatis框架那樣的SQL-MAP功能。如果有大量表單，還應該考慮這樣的數據層框架能夠支持數據控件綁定。所以一個優秀的數據層框架應該同時具備ORM，SQL-MAP,Data Controls 功能，有一款國產的SOD框架值得推薦！
