調用sp和性能策略

Question

我發現我的自我處於必須在數據庫中創建新sp並創建中間層代碼之間進行選擇的情況。所以放鬆一些寶貴的開發時間。該程序也可能包含一些連接。

或者使用兩個已經存在的sp（s），這種方法的問題是我正在做兩次往返數據庫。這可能是糟糕的表現，尤其是如果我在另一臺服務器上有數據庫

你會走哪條路？爲什麼？

謝謝

Answer 1

你已經回答了你的問題。兩次往返的效率會低得多，應該避免。

如果您沒有太多時間，則可以創建一個調用其他兩個SP的新SP。

如果創建調用新SP的代碼真的很慢，而且人們正在避免它，那麼您可能需要對整個架構提出質疑。

Answer 2

這裏您確實沒有提供足夠的信息。一般來說，我會選擇單一SP方法，除非它實際上是從數據庫中檢索的兩個非常不同的東西。我認爲存儲過程應該遵循單一責任原則，就像你的類應該那樣。

到數據庫服務器的兩次往返通常不會成爲問題;但當然取決於它的使用方式。例如，你是否需要在每個請求中檢索數據？性能至關重要？它是否在緊密的環路中使用？ （希望不是:-)

Answer 3

請記住，即使您有兩個單獨的SP，並且想要一起加入結果，第三個SP中也沒有簡單的方法在服務器端執行此操作。您可以將它們分別插入臨時表中，然後加入臨時表。

您也可以複製兩個SP中的代碼並將它們組合起來以產生所需的結果集 - 可能導致一些邏輯重複和維護問題。或者，如你所說，你可以在客戶端做到這一點。如果兩個SP不會分開返回比您想要返回更多的信息，那麼開銷不會太大（如果您可以從客戶端異步產生它們，然後將它們一起處理，它實際上可以非常高效）

所以無論如何，你已經必須做一些編碼和測試，至少有一點意義。因此，我強烈建議您考慮將兩個原始SP更改爲表值函數（如果可能，內聯）。然後，兩個原始SP可以從UDF中提取，新SP可以像加入表或視圖一樣加入兩個UDF。從代碼複製的角度以及從重用和語義角度來看，它是最簡單的SP連接機制 - UDF代碼相對容易閱讀，使用和重用 - 它們基本上像參數化視圖一樣工作。另外，優化器很好地處理內聯TVF。有些情況下複雜的SP可能導致TVF無法正常工作，但對於大多數情況，它們非常強大且高效。一個非常成功的功能，可以在任何SQL Server系統體系結構中發揮重要作用。