什麼時候寫一個長存儲過程

Question

是否有任何指導你什麼時候該寫和應該不會寫一個長而複雜的2000+行存儲過程？

在我的具體情況下，這個存儲過程包含了很多if/then，case，goto和branching語句。它的工作原理是根據查詢的輸入和結果構建SQL查詢，並使用execute語句運行構造的查詢。它可以在一次調用中執行多個構造的查詢，並使用這些查詢的結果構建其他查詢以運行。

這很麻煩，很難理解。調試很困難，要知道發生了什麼，唯一的方法就是逐步調用，看看它在做什麼。幾乎沒有任何異常處理或記錄。保持它是一種痛苦。事實上，沒有人真正知道它的作用或創建方式，如果我們必須對其進行修改，我們將不得不採取「跨越你的手指並希望最好」的方法。但是，我認爲這是出於性能原因這樣做的。

此過程被許多應用程序使用。我能想到做這種事的唯一方式就是通過網絡服務。它的複雜性可能相當，但更容易理解。但是，它可能會慢多倍，因爲它仍然需要針對1個請求對數據庫進行多次調用。

所以，我的問題是，我們如何決定何時和何時不寫長存儲過程？

有沒有我丟失的東西，或者我們只是忍受我們可怕的存儲過程？

是否有方法將存儲過程組織和分解爲更小的組件，以便它們易於理解？

當您需要對數據庫進行多次調用時，存儲過程是否總是比其他任何事情都快並且是正確的選擇？

Answer 1

我不確定爲單個函數寫入2000+ LOC是否永遠是個好主意。我最初的反應是說你的sproc應該被分解成更小的函數（表值或標量，任何適當的）和存儲過程（用於非查詢操作）。然而，這可能只是在移動LOC而不是簡化實際操作。不幸的是，沒有發佈任何源代碼，很難提供更具體的建議。

Answer 2

聽起來像你需要改變你寫和維護這個存儲過程的方式。

存儲過程是從SQL查詢創建的。也許你可以編寫一個應用程序/腳本來生成SQL來創建/更新存儲過程。

這樣做會爲您提供可重用存儲過程的所有好處（您已擁有的好處），但它會使存儲過程的維護更加輕鬆。

通過擁有2000+行存儲過程，您基本上鎖定了自己作爲唯一可以完成這項工作的人。這意味着你被困在你所在的位置，無法前進（沒有職位升遷，沒有分配給新項目等）。

Answer 3

如果您仍然遇到此問題，現在可以嘗試使用某些其他微軟語言（如C＃，Visual Basic等）的CLR（通用語言運行時集成）來對您的解決方案進行編碼。這將有助於您的代碼的調試和維護。