1、數據庫移植不方便:
2、大量採用存儲過程進行業務邏輯的開發致命的缺點是很多存儲過程不支持面向對象的設計，無法採用面向對象的方式將業務邏輯進行封裝，從而無法形成通用的可支持複用的業務邏輯框架。
3、 代碼可讀性差,相當難維護,
4、不支持羣集
金融和電信行業的確在數據庫服務器的硬件投資少不會吝惜，但是數據庫服務器是單點的，極難擴展，即便Oracle的羣集，他的共享存儲數據庫也是單點的，如果業務邏輯的運算非常消耗CPU和IO，你沒有任何有效的辦法來擴展系統的性能。
5、對於並非極度依賴數據的業務邏輯運算，如果在應用服務器端來實現的話，特別是採用SNA架構的情況下，理論上可以獲得無限的水平擴展能力，只要加服務器就行了。但如果你放在數據庫裏面，你就大眼瞪小眼了，加服務器都不管用了。
經典語錄:
1、對於那些對於性能要求極度苛刻的大負載應用，比方說阿里巴巴，擁有中國最強的Oracle DBA團隊，已經把Oracle的配置優化到極限，已經把SQL優化到極限了。他們絕對不允許程序員把業務邏輯寫成存儲過程，甚至不允許程序員創建觸發器、不允許程序員創建表的外鍵約束，外鍵關係自己在程序裏面維護。凡是能夠在應用層進行檢查的工作絕不能放在數據庫層，加重數據庫服務器的負擔。
2、我只希望大家記住一點：數據庫服務器出現CPU和IO瓶頸，你沒有辦法擴展，但是應用服務器出現CPU和IO瓶頸，你只需要加服務器就行了。
3、留戀存儲過程的，我想大多數人可能是最近幾年都脫離了實際的開發的人。記得當初某人曾說，用存儲過程吧，反正這個業務10年也不會發生變化。而且我還不是在一個人那裏聽到的這個說。但是這些系統僅僅過了三年就要升級，因爲業務規模和企業需求的發展大大超乎當初的設想。
4、不要以爲一種技術理論開始流行僅僅是人們的炒作。把業務分層，與數據和顯示、硬件隔離的思想，已經出現了20年了。可以說分層的思想一出現，人們就在說這個問題。而且一直對這個問題的看法如此一致。這些都是建立在大量的大規模企業應用的基礎上得到的血的教訓帶來的。
5、可以說即便硬件的更新再快，也趕不上需求的要求。CPU和IO瓶頸，昨天是，今天是，明天依舊是問題。而一旦需求來了，不會有時間給你去解決這個問題。這個時候最簡單的方式，就是直接加點應用服務器。這個方法比任何方法都見效快，而且往往也最便宜。
6、有點疑惑，如果把大量的業務邏輯放到webserver來處理，那麼webserver和dbserver之間數據的傳輸量肯定會比把業務放到dbserver進行處理，然後dbserver只返回少量處理後的數據多。
7、當訪問量大規模提高之後，webserver和dbserver這種傳輸的消耗肯定也要打規模提高。這個地方如果出現瓶頸是能用添加服務器來解決的？
我不妨給你一個數據參考參考，JavaEye每天是70萬頁面訪問量，處理80萬動態請求，訪問峯值的時候Web服務器和DB服務器之間的網絡數據傳輸量是2MB每秒，平均每秒傳輸不到1MB。 我就算你的企業應用系統每天有800萬動態請求，你服務器之間的峯值數據傳輸量也不過20MB每秒而已。好吧，也許你又說JavaEye處理的數據量不夠大，我再給你擴大5倍，算你峯值每秒數據傳輸量100MB，夠不夠大？ 可即便如此，現在隨隨便便的普通臺式機的網卡都已經是千兆網卡了，處理你這峯值每秒100MB簡直輕而易舉，更不要說專用的高速服務器網卡了。對於大規模的羣集應用，有更加高速的光纖，每秒幾GB都不成問題，但你要真有每秒幾GB的數據量，嘿嘿，老實告訴你，中國還沒有多少企業應用系統有這麼大的網絡數據傳輸的需求。
6、非極度依賴數據庫的業務邏輯，我想不會有人放到PL/SQL中去。
7、設放在pl/sql裏的都是那種極度依賴數據的業務邏輯（我們公司就是這樣）。
來來回回的找表運算，來來回回，運算。
這種運算。你從PL/SQL中抽出，現在放到應用端來做。
好，過了一年，發現數據量大了，速度不夠用了。
這個時候你加應用服務器有用嗎？沒有用，加再多都不行。
因爲真正的耗時最終還是被傳遞到DB上面。你只能加強，優化DB。沒有別的辦法。
對於大數據量的OLAP運算，根本不能放在應用服務器端來執行。因爲很容易就會讓你的應用服務器內存溢出，導致你整個業務系統無法訪問。
對於企業應用來說，有的是OLTP型的，有的是OLAP型的，也有兼而有之的。對於OLTP型的應用邏輯一定要放在應用服務器來執行，而對於OLAP型的應用的確適合使用存儲過程來實現，用應用服務器去運算根本不行。不過一般說來，大部分的OLAP運算並不是實時性要求很高的，所以往往可以用存儲過程實現以後，作爲後臺任務定期執行，這些後臺任務往往會執行好幾個小時才能結束，然後把執行結果保存下來。讓應用服務器在展示報表的時候讀取最終查詢結果。
應用服務器羣集和存儲過程本來沒有什麼關係。但如果有人說，業務邏輯應該寫在存儲過程裏面，就有非常大的關係了。而這個帖子所要討論的問題就是：業務邏輯究竟應該還不應該寫在存儲過程裏面。顯然很多人認爲：不管三七二十一，業務邏輯都應該放在存儲過程裏面。
而我要告訴大家的是，除了那些對大數據處理非常依賴的操作，其他所有的業務邏輯統統不應該用存儲過程來實現，而應該放在應用服務器層實現。而WebSphere羣集解決的就是當應用層業務邏輯負載太大的情況下，如何進行擴展的問題。
不過話說回來，並不是每個企業應用的瓶頸都在數據庫端，即便瓶頸在數據庫端，不一定非要通過優化DB來解決，其他的辦法多的是。