SQL Serverストアドプロシージャのリビジョンの履歴を保持する方法


22

注:完全なバージョン管理については質問していません。

SQL Serverのストアドプロシージャの履歴を自動的に保持する方法はありますか。

Googleドキュメントがドキュメントのバージョンの履歴を自動的に保持し、ウィキペディアが記事のバージョンの履歴を自動的に保持する方法と同様です。

ストアドプロシージャを更新するユーザーが、ストアドプロシージャのリポジトリも維持する必要はありません。これは大変な作業であり、人々はそれをしません。

うまくいけば、これがSQL Serverでオンにできることです...

(そして、ストアドプロシージャとは、実際には関数、トリガーなどを意味します。基本的にはプログラマビリティのすべてです。)

/programming/14522224/how-to-keep-history-of-sql-server-stored-procedure-revisions first cos に投稿しました。


コメントは詳細なディスカッション用ではありません。この会話はチャットに移動さました
ポールホワイトはGoFundMonicaを言う

回答:


31

ソース管理がこれを行う正しい方法であることに完全に同意しますが、すべての環境がそれだけに依存しているとは限らないことを理解しています。実行して、クライアントを保存します。

DDLトリガーを使用して、すべてのリビジョンを別のデータベースのテーブルに保持できます(もちろん、頻繁にそのデータベースをバックアップします)。ユーティリティデータベースがあると仮定します。

USE Utility;
GO


CREATE TABLE dbo.ProcedureChanges
(
    EventDate    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    EventType    NVARCHAR(100),
    EventDDL     NVARCHAR(MAX),
    DatabaseName NVARCHAR(255),
    SchemaName   NVARCHAR(255),
    ObjectName   NVARCHAR(255),
    HostName     NVARCHAR(255),
    IPAddress    VARCHAR(32),
    ProgramName  NVARCHAR(255),
    LoginName    NVARCHAR(255)
);

データベースで、最初に「初期制御」と呼ばれるストアドプロシージャの現在のバージョンを取得します。

USE YourDB;
GO

INSERT Utility.dbo.ProcedureChanges
(
    EventType,
    EventDDL,
    DatabaseName,
    SchemaName,
    ObjectName
)
SELECT
    N'Initial control',
    OBJECT_DEFINITION([object_id]),
    DB_NAME(),
    OBJECT_SCHEMA_NAME([object_id]),
    OBJECT_NAME([object_id])
FROM
    sys.procedures;

次に、後続の変更をキャプチャするために、DDLトリガーをデータベースに追加します。

USE YourDB;
GO

CREATE TRIGGER CaptureStoredProcedureChanges
    ON DATABASE
    FOR CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @EventData XML = EVENTDATA(), @ip VARCHAR(32);

    SELECT @ip = client_net_address
        FROM sys.dm_exec_connections
        WHERE session_id = @@SPID;

    INSERT Utility.dbo.ProcedureChanges
    (
        EventType,
        EventDDL,
        SchemaName,
        ObjectName,
        DatabaseName,
        HostName,
        IPAddress,
        ProgramName,
        LoginName
    )
    SELECT
        @EventData.value('(/EVENT_INSTANCE/EventType)[1]',   'NVARCHAR(100)'), 
        @EventData.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'NVARCHAR(MAX)'),
        @EventData.value('(/EVENT_INSTANCE/SchemaName)[1]',  'NVARCHAR(255)'), 
        @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]',  'NVARCHAR(255)'),
        DB_NAME(), HOST_NAME(), @ip, PROGRAM_NAME(), SUSER_SNAME();
END
GO

時間が経つにつれて、手順の変更を確認および比較し、新しい手順がシステムに追加されるのを確認し、手順がドロップされるのを確認し、これらのイベントについて誰と話すのかを知ることが容易になります。

詳細はこちら:

http://www.mssqltips.com/sqlservertip/2085/sql-server-ddl-triggers-to-track-all-database-changes/


2
+1最も簡単でネイティブな方法。私の推測では、これはOPが探していた答えです。
トーマスストリンガー

うん、これはOPの問題の解決策になります。
マリアン

この回答が気に入ったのは、一度実行すれば追加費用なしで自動バージョン管理を取得できるからです。ソース管理とは異なりますが、無視してはならない貴重なセーフティネットです。
ダニエルウィリアムズ

2

SQLソースコードをバージョン管理下に自動的に保持する方法はないと思います。つまり、ネイティブSQL Serverツールです。最終的にgitまたはsvnを使用できると思いますが、データベース(およびストアドプロシージャ)をバージョン管理するためにRed Gateのソース管理を購入するのが最善の解決策でした。


1
確かに、DDLトリガーは、サードパーティのツールを必要とせずにこれを行うことができます(私の答えを参照)。もちろん、ソース管理ははるかに優れた制御と監査を提供し、サードパーティのツールには自分で書きたいものよりも多くの機能がありますが、直接的な変更から保護する方法はありません。ソース管理プロトコルに従ったすべての人(これは常に実行可能ではありません)。
アーロンバートランド
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.