以下列方式創建SQL Server存儲過程的缺點是什麼？

我們爲您在我們所有的數據庫對象到源代碼控制，rerunnable腳本（視圖，函數，觸發器&存儲過程等）以下列方式創建SQL Server存儲過程的缺點是什麼？

當談到時間部署，我們需要確保所有的腳本重新-runnable &可重複，以便存儲過程被創建/更新到最新版本。

以下列方式創建腳本有什麼缺點嗎？

IF NOT EXISTS 
(
    SELECT  * 
    FROM  INFORMATION_SCHEMA.ROUTINES 
    WHERE  ROUTINE_SCHEMA = 'dbo' 
    AND   ROUTINE_NAME = 'MyStoredProcedure' 
) 
BEGIN 
    EXEC ('CREATE PROCEDURE [dbo].[MyStoredProcedure] AS SELECT 1') 
    -- ALSO DO ANY INITIAL GRANT PRIVILEGE SCRIPTING HERE 
END 
GO 
ALTER PROCEDURE [dbo].[MyStoredProcedure] (
    @param1 INT, 
    @param2 NVARCHAR(50) = 'Default String' 
) 
AS 
BEGIN 
    -- DO SOMETHING WITH @param1 AND @param2 
    SELECT 1; 
END 
GO

本質上的腳本檢查是否在相關的系統視圖中存在的對象，如果它不存在，一些動態SQL創建它作爲存根，以避開CREATE PROCEDURE/GO陳述問題沒有被允許在條件塊。然後它通過ALTER應用腳本的實際功能。

所以好處對我來說是顯而易見的，我只是想知道這樣做有什麼不利之處......除了編寫稍微更冗長的腳本的輕微開銷之外。

來源

2012-12-20 Eoin Campbell

根據您的說法，您可能會得到一些近距離/主觀投票，而且這可能更適合DBA，但我覺得這是一個有趣的解決方案，可以解決我們在之前的公司中遇到的問題。 – Joe

嗯，我想我正在尋找合法的技術「缺點」......即是否有任何技術上的理由「DROP/CREATE」而不是「ALTERING」？「ALTERS」能否對執行計劃等產生任何影響...... –

SQL Server差不多已經有20年的歷史了，他們還沒有開始實施'CREATE OR REPLACE'命令。 – SWeko

這裏是10年的SQL Server開發人員/架構師，除了創建腳本的相對輕微的前期成本之外，我想不出任何其他缺點。

如果您擔心在創建時編譯爲平凡的計劃在ALTERed過程中沒有重新編譯，您可以爲每個計劃添加對SP_RECOMPILE的顯式調用，但是我從來沒有將此問題與SQL Server （我已經和DB2一起使用過），所以我認爲這是非常謹慎的。

這是一個有趣的，我認爲有用的方法。

來源

2012-12-20 12:57:19 DeanGC

SQL Server在SP創建時不編譯計劃。它在創建時被解析，但是在第一次執行時被編譯並且運行'ALTER PROC'會無論如何都會使任何緩存的計劃無效。 –

你當然是對的。 :)我可能不應該說'在創作時'。當應用程序框架在編譯和鏈接時執行存儲過程，並且僅在DB2中執行時，我遇到過這種情況。正如我所說，我認爲這是一種過度的謹慎 - 這實際上是我能想到的唯一反對或警告。 – DeanGC

感謝Dean＆Martin的反饋。〜EoinC –

以下列方式創建SQL Server存儲過程的缺點是什麼？

回答

相關問題