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

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服務器更新應用來滿足需求的變化。

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

關注技術文章飛秋：http://www.freeeim.com/，24小時專業轉載。

總結

以上是生活随笔為你收集整理的【飞秋】存储过程与业务类实现业务的差异比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。