商務邏輯實現方式的討論：預存程序 good or bad?

之前國內外都對預存程序的好與壞進行了激烈的爭論，以下是一些調查與討論的連結，有興趣可以去瞭解一下：http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspxhttp://www.oreillynet.com/databases/blog/2007/03/_so_are_database_stored_proced.htmlhttp://andrewonedegree.wordpress.com/2010/03/08/are-stored-procedures-good-or-bad-and-when-to-use-them/ （推薦）http://www.cnblogs.com/cxd4321/archive/2008/03/21/1115881.html 

 

本文將不討論這部分內容，更重要的強調什麼情況下使用預存程序，什麼情況下應該封裝在業務類中。總體的原則：1、商務邏輯需要進行複雜的判斷處理使用業務類實現2、涉及小資料量（資料行在200條以內）處理判斷使用業務類實現3、涉及批量資料處理使用預存程序實現（如部門人員批量合并，同時批量增加每個人員的崗位變更資訊子表）4、涉及統計分析部分的邏輯通過預存程序來實現5、如果需要對外提供資料層介面的部分通過預存程序實現，不建議直接開放資料表，至少也要以視圖的形式開放（這種情況很少，一般是內部系統間才會使用這種介面，建議少用）6、需要進行橫向擴充的業務使用業務類實現（如：使用者認證表只是縱向擴充，只是記錄的增加；企業的數量可能的增長就屬於橫向擴充或者說模組的數量增長也屬於橫向擴充，涉及資料表的增加部分） 

當然在大多數情況下，需要具體情況具體分析，以下只是針對我目前項目情況的分析：1、只支援Oracle資料庫。即Oracle10g及以上版本的資料庫。因為是做SAAS服務，所以客戶不需要關心資料庫，為此產品沒有適應多種資料庫環境的需求。2、模組低耦合。如使用者認證、註冊、具體商務邏輯模組應用等進行物理上的分離，提供的資料庫儲存及服務都分布在不同的資料庫伺服器或者執行個體上。3、對可擴充性要求比較高，要求可進行多種方式的擴充（如部署方面可以通過橫向增加伺服器的方式解決高並發的問題，業務方面要求可以適應不斷增加的功能模組，以適應企業管理的需要）。4、對可靠性要求比較高，要求可提供7*24不間斷服務。 

總結：通過Web伺服器部署商務邏輯層的執行在橫向擴充性能方面存在很大的優勢。但在某些方面還是存在一些問題，同時也要考驗開發人員的水平與代碼的品質，對需求變更的適應性及響應的及時性等等方面。Oracle本身提供了一些資料庫負載的解決方案，雖然我不是OracleDBA，但Oracle在資料庫方面的成就還是非凡的。據我所瞭解的情況，探索資料庫存在瓶頸的時候，除了最佳化一些SQL語句的執行效率之外，最先要做的就是資料庫的讀寫分離，大大減少對IO資源的壓力。在其它方面應該還有一些解決方案，至少之前在電信、電力、稅務等大型應用下Oracle資料庫本身並沒有存在很大的問題（可能是DBA都解決掉了吧）。而在我的經驗中大部分出問題的反而是程式本身，一方面是比較難快速的適應需求變更，另一方面是比較難定位問題。後者很大的原因是沒有做好單元測試，造成問題定位困難，造成測試跟蹤起來太麻煩。