存儲過程:
1.編譯後生成中間代碼，該代碼的執行效率遠比客戶端數據庫訪問快,但是大多數高級的數據庫系統都有statementcache的，所以編譯sql的花費沒什麼影響。但是執行存儲過程要比直接執行sql花費更多（檢查權限等），所以對於很簡單的sql，存儲過程沒有什麼優勢。
2.使用的是服務器端遊標，而客戶端程序使用的是客戶端遊標，速度快
3.不需要象 J2EE 的程序那樣要部署，適當的時候只需在後臺更新，便於調試與維護
4.佔用網絡流量較少，如果在存儲過程中沒有多次數據交互，那麼實際上網絡傳輸量和直接sql是一樣的。
應用層:
1.一般性的業務邏輯應該放在中間層，這對軟件以後的技術擴展有很多好處，像網格技術，就是基於中間件技術的。
2、性能擴展性問題：隨着系統訪問量的增長，系統必須進行不斷地升級擴展，特別對於大型系統而言，更重要的是性能可擴展性而不是局部的性能。J2EE等多層結構要解決的也是這方面的問題。處理邏輯如果全部放在存儲過程裏，所有的處理都在數據庫服務器上進行，消耗的就是數據庫服務器的CPU資源，大家知道數據庫服務器由於需要較高的可靠性，通常選用的都是價格昂貴的服務器，對數據庫服務器升級通常都花費很大。如果把處理邏輯放在中間層服務器上進行，中間層服務器一般都是小型的機器，價格便宜，而且中間層服務器的CPU通常主頻比數據庫服務器的速度還快（比如現在8CPU的數據庫服務器主頻只有800M，而雙CPU的刀片式服務器CPU主頻已經到2.8G了），而且對於多層架構，支持中間層服務器可以增加多臺機器進行負載均衡，用中間層服務器即價格便宜，擴展空間也更大。
3、開發問題：存儲過程還是過程型語言，其重用性比不上JAVA等面嚮對象語言開發。用JAVA開發的中間層服務可服用性更好（當然，前提是你採用面向對象設計）
4. 實際上這個只是要將訪問數據庫的接口統一，是用存儲過程，還是EJB，沒太大關係，也就是說，在三層結構中，單獨設計出一個數據訪問層，同樣能實現這個目標。
總結：
1.存儲過程是基於計算密集型的業務邏輯。如果是基於操作密集型的就不要用存儲過程了
2.所有數據訪問在應用層封裝爲數據訪問層，在那裏，如果SQL簡單的話，直接用SQL；如果SQL複雜，或者數據交互多且中間數據最後不會用到，使用存儲過程
3.（對於核心的算法，不變的東西放在前臺程序中。對於容易改變的字典數據，接口邏輯和配置信息，可以放在後臺用存儲過程來完成。最大好處，也是最終目的是：源程序不改，只改後臺存儲過程就可以瀟灑應付客戶需求的改變。）這個不知道對不對
觸發器一般是用於在一個表的數據更新後，觸發相關表實現聯動更改，這樣做有一個好處就是在進行數據更新時，只要更新一處數據，其他業務邏輯需要修改的地方就能全部交由數據庫定義的觸發器在數據庫層面修改其他表的數據。
這些業務，比如說用戶登錄動作，在用戶登錄後，我們只要更新最後登錄時間，同時通過觸發器，來把用戶的信息放到在線用戶表裏，另外也可以定義觸發器在消息表裏生成一些數據來推送給用戶等等。
不過以我以往的經驗，我建議最好不要使用觸發器，可以使用隊列來實現類似的功能，主要原因：
1.建立了觸發器後，各表間就形成了一種耦合關係，當數據量大了以後，想做數據拆分、數據庫變更、數據庫存儲優化等等，都非常困難了，有的甚至動不了，比如我以前經歷過的一個系統，開始使用的是sqlserver數據庫，上面自定義了一些觸發器，不過後來數據量大了，想使用mysql來分離一些數據，但系統又要一直保持在線可用狀態，想整改優化系統的存儲，非常痛苦！
2.在數據庫的使用原則上，我建議，最好只使用數據的存儲跟查詢這些最基本的功能，儘量減少數據庫的邏輯運算，這樣才能最大程度的發揮數據庫性能，也更有利於系統的性能擴展，減低系統耦合性等。