我們的系統在原來設計時的採用SP(存儲過程)的總結:
SP最適用於報表這種大量SQL的組合,因爲放在代碼中組合大複雜,而集中放在SP中易於維護,速度快.
但如果是大量用戶訪問時,數據庫性能沒有辦法提高它,而做在中間層代碼就有得擴展(如CLB).並且易於移植到其它數據庫.
也就是說我們的管理系統用戶量少,在報表中可使用SP;而通訊系統(要擴展性能)使用代碼組合SQL有利於以後擴展.
因此並不能象我們以前討論那樣,並不是SP好還是組合SQL語句好.就看你用到那裏,
總結幾點:
1.如果有比較複雜的業務邏輯 不建議採用SP(這要求程序員還要非常熟悉SQL才能讀懂業務)
2.考慮移植性和擴展性 不建議採用SP
3.系統較大,考慮系統部署方便性,系統的分層性 不建議採用SP
4.碰到需要處理事務，回滾等內容 建議採用SP
5.考慮長久的維護性,調試和查問題複雜化,版本控制 不建議採用SP
6.SP一定要有文檔對應,否則交互的系統一多,就不知道存儲過程做什麼的了!