很早的時候我被我們領導灌輸過一個思想我們領導當時是做WEB出身的他非常重視WEB的功能在他眼裡數據庫只是存放數據的箱子不應該把過多的業務邏輯交給數據庫去處理應該只把他看做是存放數據的箱子我們當時是用MySQL + php那時候MySQL比較弱一些不支持存儲過程觸發器事務等等正好符合我們領導所提倡的理念
後來接觸了ERP發現數據量很大全部用VB等處理效率低速度也慢采用存儲過程效率高而且有些Bug新功能只要在數據庫服務器上進行修改存儲過程就可以了客戶端都不用修改程序感覺這個存儲過程很強大而且通過存儲過程還可以做其他軟件的數據庫接口自從那以後就瘋狂癡迷於存儲過程數據庫技術經常研究這些方面的技術
又過了些日子接觸了Oracle發現與SQLSever裡的存儲過程不兼容有些寫法用法理念差距也很大移植問題是個很大的麻煩雖然理論是完全可以移植的但是要維護套這樣的系統麻煩很多所以開始漸漸的放棄寫存儲過程這個愛好了盡量寫一些簡單的SQL語句的組合盡量把商業邏輯都寫在C#裡好調試些隨著對C#語法的深入理解商業邏輯寫在C#裡的開發速度比寫在存儲過程裡還快了很多再接著對系統整體功能的定位漸漸放棄了局部功能的優化思想以考慮全局為重不差那麼秒的性能速度提高不在乎這些一點點的差距
最近幾年由於對面向服務編程的深入理解徹底放棄寫存儲過程了盡量商業邏輯都寫在C#裡因為客戶有可能是買了正版的Oracle或者購買了正版的SQLServer 他們希望你的程序能跑在他們的正版數據庫系統上而不是為了使用你的系統又重新購買另一套正版軟件
基於存儲過程的數據庫腳本的主要缺點是調試起來麻煩數據庫中的表字段變動了也不提示關聯錯誤也沒有版本控制很容易丟失腳本程序而且人人都有一個本地數據庫很容易把存儲過程搞亂套了最後會導致誰都不知道到底哪個才是最新的存儲過程而且給上百個存儲過程起個合理的名稱這個命名工作統一規范化也是個要命的問題
把商業邏輯寫在C#裡的好處就很多了有相應的版本控制器以前的代碼也可以找出來不怕丟失代碼有些修改程序等造成的錯誤在開發環境編譯階段就能發現錯誤在哪裡好進行關聯修正多種版本的數據庫上移植也簡單些也不用同時兩邊作戰又要維護數據的版本又要維護程序的版本發布時也會遇到方面都需要更新的問題還是單邊作戰比較簡單一些同時與其他系統的接口等
交給相應的服務程序進行處理由服務程序來負責與其他系統的交互這個交互又比底層數據庫的交互強大很多
我曾經寫過一個小軟件裡面大量采用了存儲過程給我的痛苦總結下來是 數據庫中的表進行了修正了我不知道哪幾個存儲過程需要修正？
有時候手上好幾個數據庫測試來測試去很容易不知道到底哪個是最新的特別是過了一年半載再去找對應的數據庫時這個問題很明顯
調試C#程序很容易調試存儲過程相對麻煩一些
參數有變動時還要修改存儲過程的參數有時候還有關聯的存儲過程需要修正很折騰人而且運行了才能發現這些問題
還有這個程序只能跑在SQLServer上還好我們用的都是D版想安裝就裝了也不要錢若真要錢那不是開玩笑的
現在我們開發的很多系統裡根本看不到存儲過程的影子了當然我們也不是走極端在平時一些簡單的系統裡還真沒多大必要用到存儲過程能不用就不用吧多一事不如少一事現在總結已經走過的路感覺還是商業邏輯盡量寫在C#裡是省心省力的正確道路
From:http://tw.wingwit.com/Article/program/net/201311/12497.html
