儲存過程與業務類實現業務的差異比較

以下比較不太全面，純粹是個人的理解。可能是針對前一篇文章的補充與說明

1、批量資料的處理比較

業務邏輯：單位a部門劃轉到b部門，業務規則是把a部門的100人的關聯單位改為b部門，同時在人員崗位變化子表裡增加一條變動記錄。

業務實現：

1）儲存過程實現（sp實現)（兩個sql語句）

insert into 崗位變化子表（變化前部門、變化前崗位、變化後部門、變化後崗位、生效時間、操作人、操作時間） select a,崗位,b,崗位,sysdate,當前登入使用者,sysdate from 員工表 where 部門id=a；--完成插入100條子表的資料

update 員工表 set 部門id=b where 部門id=a; --更新員工的部門關聯

commit; --最後提交，sp本身就開啟了事務機制，所以可以放心操作。

2）業務類實現1（符合物件導向的原則）

獲得a部門員工物件，一般是100個員工物件的collection，即生成的sql語句是把所有的員工表的字段都查詢出來，然後迴圈進行員工物件屬性的變更與儲存、子物件的建立與儲存等業務。

3）業務類實現2（有點不太符合物件導向的原則，但效率肯定比前面一種高）

按sp方式執行sql語句。當然要注意開啟事務處理，否則可能會產生垃圾資料喲。

當然可能還有除了這三種之外的實現方式，但這三種應該是最常見的了。其它的內容這裡就不展開說了。希望非專業人士可以看明白。專業人士可以自行計算一下資料庫連線的次數及需要傳輸的資料量。

需求變更：增加操作ip的記錄

所有都要做的事情：增加【崗位變化子表】資料表字段：操作ip

1）sp調整

增加引數ip，修改第一條insert語句即可。

關聯修改：呼叫儲存過程方法重新調整。重新編譯發布

2）業務實現1

修改崗位變化子表的實體類。（一般是重新生成即可）

修改業務邏輯類

重新編譯發布

3）業務實現2

修改崗位變化子表的實體類。（一般是重新生成即可）

修改sql語句

重新編譯發布

2、資料統計類

業務邏輯：定時（每小時或每天）更新使用者排行榜（如積分排行榜），假設使用者積分資料8千萬條資料。

業務實現：sp的方式

建立乙個job佇列執行設定的儲存過程，把統計的結果存到積分排行榜的資料表裡。

適應需求變化：統計的規則可能經常變化，特別是積分系統的調整也是非常頻繁的（可能一周就會有一次，特別是專案上線前期），儲存過程可以很快的修改測試與部署。不需要指定專門的時間去停止所有的web伺服器更新應用來滿足需求的變化。

先寫這些吧，寫東西太耗時間了。還是等壓力測試的資料出來再做一些分析吧。