5

すべてのデータベース オブジェクトを再実行可能なスクリプト (ビュー、関数、トリガー、ストアド プロシージャなど) としてソース管理にチェックインします。

展開するときが来たら、すべてのスクリプトが再実行可能で繰り返し可能であることを確認して、ストアド プロシージャを作成/最新バージョンに更新できるようにする必要があります。

次の方法でスクリプトを作成することの欠点はありますか。

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

基本的に、スクリプトは関連するシステム ビューにオブジェクトが存在するかどうかを確認し、存在しない場合はCREATE PROCEDURE/GO、条件付きブロックで許可されていないステートメントの問題を回避するために、一部の動的 SQL がオブジェクトをスタブとして作成します。次に、 を介してスクリプトの実際の機能を適用しますALTER。

したがって、利点は明らかです。これを行うことには欠点があるのではないかと思っています...少し冗長なスクリプトを書くことによるわずかなオーバーヘッドを除いて。

4

1 に答える 1

2

ここでは 10 年の SQL Server 開発者/アーキテクトですが、これを行うスクリプトを作成するための (比較的わずかな) 初期費用以外にマイナス面は考えられません。

作成時に単純なものとしてコンパイルされたプランが、プロシージャが変更されたときに再コンパイルされないことが懸念される場合は、それぞれに対して SP_RECOMPILE への明示的な呼び出しを追加できますが、SQL Server でこの問題が発生したことはありません (私は持っていましたそれはDB2で）なので、それは過度の注意だと思います。

これは興味深いアプローチであり、有用なアプローチだと思います。

于 2012-12-20T12:57:19.903 に答える