应用服务器看来应该避免多表查询

一直沒有仔細考慮在自已的hanva框架中多表查詢的情況。今天算是真實碰到了，並不算太緊，這時侯正好可以較詳細地思考這個比較理論化的問題。事實上， 當表達層變得需要通過應用層去訪問數據庫時，如同J2EE試圖做到的一樣，單個的實體bean不會有太大的問題；而如果是條件性列表，就已經比較麻煩了， 如果是多表的話，原則上無法繼續。

原因就在於這種三層結構需要使用相應的預編寫的java類去承接查詢回來的數據。對於實體bean來說，對象就是數據記錄的虛擬反應，倒也沒有什麼區別； 但如果是多表連接的查詢，同時不應該每寫一個查詢需要特別生成一個java類（否則效率何在，還談何方便？），在邏輯上，基本上是說不通的；因為，那個反 應多表限制的類，它在實際意義上代表的是什麼對象呢？

目前對這種情況我是通過database外置基類加以解決，對於大多數情況下，基表只是一個小小的表，使用XML-內存映射的方式不但可以獲得更高的效 率，而且，還可以把絕大部分列表查詢簡化成高效率的單表查詢，（每一個表連接意味著多一次遍歷），並進一步地可以適應多數據庫的環境，實際運行效果非常 好。但這種代入內存的方式如果基記錄的數量很大，就不劃算了，效率也會直線下降，最終不如使用數據庫的傳統的多表查詢更為合理。

另一種辦法就是使用非規範性的操作，預先把本來需要實時多表連接產生的結果以非規範化的方式寫在相應的表記錄中，這樣，同樣可以把多表查詢簡化為單表查詢。事實上，這也是在系統優化過程中大量使用的提高運行效率的常用的方法。

使用上面這兩種方法，基本上可以避免產生真正的多表查詢，事實上，幾乎過了一年，才碰到可能需要多表連接的情況，就是一種證明；而且即使是目前的需要，也 是可以通過上面的第二種方法解決的。如果仍然想偷懶，那就直接採用傳統的操作sql/resultset的辦法，從而避開中間的應用服驄器的限制是也，也 仍然沒有必要把精力放在讓應用服務器適用多表查詢上。多表查詢的需求，完全可以通過範式的更改來加以避免。

無論是j2ee,hibernate,libernate難以真正成為開發的標准（得到４0%以上的應用），看來犯的一個共同的錯誤，就是把超過８０％的開發精力投入到實際上並不是必須多表連接上，實際上卻是降低了整個方案的可用性和適用性。