存儲過程與數據庫查詢中的代碼

Question

我在這裏有一個很好的問題。

什麼是訪問數據庫使用ASP.NET的CodeFile反對使用SQL存儲過程

爲了方便使用的查詢，來維護及更改時編碼查詢更容易，尤其之間的性能差異。

如何將存儲過程編譯到數據庫中並由數據庫運行！

哪一個更高效，更好用？

Answer 1

SQL Server緩存任何查詢的執行計劃，SPROC與否。這裏幾乎沒有區別。基本上，當使用存儲過程時，您可以省去通過網絡發送查詢文本，僅此而已。來源：http://msdn.microsoft.com/en-us/library/ms181055.aspx

沒有和特殊的原因存在，做什麼更方便你。

其他答案表明sprocs性能總體上更好，這是不正確的。

Answer 2

只要是以數據庫爲中心的查詢，那麼存儲過程在大多數情況下會是更快的選擇（性能）。

但它很難維護，因爲它不在你的常規源包中。

「更好使用」取決於要求。如果查詢稍慢一點（比如1 ms VS 3 ms），那麼將其保存在一起並將其放在ASP中。如果性能是你想把它放在數據庫中。

我把大部分查詢放在代碼中，只有那些需要數據庫性能的查詢。

當然，它也取決於所使用的數據庫系統。

Answer 3

你的問題是非常不完整的，你真的比較。

無論SQL代碼是在存儲過程中還是從客戶端提交的完整內聯SQL語句通常幾乎沒有什麼區別（假設正確的參數化和SQL是非病態的）性能。它可以在安全體系結構和訪問需要給予基表或視圖而不是程序的執行權方面產生很大的差異。存儲過程鼓勵參數化作爲需求，但內聯SQL也可以實現參數化。

如果您正在討論針對從數據庫返回的數據集執行邏輯而不是數據庫中的工作，這可以通過兩種方式實現 - 這取決於操作類型，索引類型，客戶端和數據庫之間的帶寬和需要服務的請求數量。

通常，我會首先考慮在數據庫中執行此操作，以保持從客戶端抽象連接/循環邏輯並減少連線（列和行）上的數據，並向客戶端呈現簡單的數據集API ，但是IT依賴。

Answer 4

這是一個「取決於」的問題。
假定這是SQL Server 2008 R2或更高版本的標準版或企業版，存儲過程將緩存與TSQL語句不同的緩存。由於諸如參數化，代碼編譯，參數嗅探和各種其他優化等多種事情，複雜的T-SQL語句幾乎總是會比存儲過程執行得更差。一般來說，我更喜歡存儲過程，因爲它們更容易優化。此外，您可以更改存儲過程，而無需重新編譯和重新部署任何代碼。當參數值急劇變化時，優化（例如「爲未知優化」或 「with recompile」可以應用於存儲過程）可以應用於存儲過程，並且在沒有最終用戶注意的情況下不會執行優化（除了性能改變）。

一次存儲過程總是會在計劃緩存中結束，並且永遠不會被視爲臨時查詢。臨時查詢（取決於SQL設置）可能或不可能存儲在計劃緩存中。加上或刪除一個字符（假定它沒有被參數化）會導致SQL Server建立一個新的計劃，並且建立新的計劃是一個緩慢的操作。

TL; DR - 預設SQL Server 2008R2或更高版本Standard/Enterprise;對於簡單的查詢，你會注意到沒有區別。對於複雜的查詢，存儲過程（如果編寫正確）幾乎總是會執行T-SQL。存儲過程在以後也更容易優化。

編輯 - 在SQL版本中添加。我不確定較舊的SQL版本。