存儲過程應該很多還是集中？

Question

你應該如何通用你的存儲過程？他們應該被視爲「一擊」還是鏡像更普遍的用途？考慮以下情況：

1.

• FindUser（用戶名，...）

  存儲過程返回的用戶ID給調用者

• 的FindItem（ITEMNAME，.. ）

  存儲過程將該物品ID重新發送給呼叫者

• AddOrder（用戶ID，爲itemid，...）

  返回然後IDS可以被傳遞到所述第三存儲過程

2.

• AddOrder（用戶名，ITEMNAME。 ..）

這裏，ID的查找，在存儲過程中完成的

是否有首選/推薦的方式？謝謝你的想法。

Answer 1

不要陷入這樣一種想法，即必須管理/維護許多簡單的特效比較困難，只有少數複雜的特效。我總是發現，無論何時我們試圖讓一個過程執行多個事情而不是一個重點事件，調試和測試變得更加困難。

你說「應該存儲過程很多還是集中？」，我會建議這是一個不正確的比較。

如果你有很多存儲過程，那麼它們會更加專注，因爲它們會更小，更少。也許你的意思是問「許多重點存儲過程，或更少更廣泛的存儲過程？」

還應該使用db ghost等工具來控制存儲過程代碼（和模式），以便像處理其他代碼一樣對待它。有了這個，許多小程序的管理就更容易了。

這實際上只是將關注點分離的核心優秀設計實踐應用到您的「數據庫代碼」以及所有其他代碼。

正如另一個答案也說，我是一個使用存儲過程來「緊縮」你的數據，儘可能靠近數據庫，如報告特效的粉絲。這是由於性能的原因，即讓數據庫去做它擅長的事情。

但是，當涉及到很多其他類型的「業務邏輯」時，我們通常會盡量避免存儲過程中的代碼，並且在普通代碼中我們有更好的調試和測試工具。

Answer 2

就我個人而言，我會選擇多個oneHit SP，因爲創建一個矮胖的增加了很多錯誤處理的複雜性。無效的商品名稱，但有效的用戶名等......另一方面，人們可能會認爲，從性能角度來看，矮塊可能會更好。

我會去多者，但我interessted過什麼其他的想法都是圍繞...

+1的提問。

ķ

Answer 3

我相信，存儲過程應該用於數據密集型業務邏輯，這裏的計算可能過於性能在應用密集。

擁有複雜的sp，將計算放在數據庫層，避免大量的數據集傳輸到應用程序。這也將允許程序員在無需重新編譯的情況下更改功能，但可能會減慢調試速度。

我發現使用sps僅僅通過鍵（例如userid）或特定字段檢索對象（例如用戶）的數據主要是使用自動生成的數據訪問層發現的，而且我們發現很多次，每個對象都會生成許多sps。

我們試圖限制sps報告數據集和複雜的數據計算/操作。