Comment conserver l'historique des révisions de procédures stockées SQL Server

Remarque: je ne pose pas de question sur le contrôle de version complet.

Existe-t-il un moyen de conserver automatiquement un historique des procédures stockées sur SQL Server.

Similaire à la façon dont Google Docs conserve automatiquement un historique des versions des documents et Wikipedia conserve automatiquement un historique des versions des articles.

Je ne veux pas que les utilisateurs qui mettent à jour des procédures stockées aient également à maintenir un référentiel de procédures stockées. C'est trop de travail et les gens ne le feront pas.

J'espère que c'est quelque chose que je peux activer dans SQL Server ...

(Et par procédures stockées, j'entends vraiment les fonctions, les déclencheurs, etc. Fondamentalement, tout sous Programmabilité.)

J'ai posté sur /programming/14522224/how-to-keep-history-of-sql-server-stored-procedure-revisions d' abord parce que je soupçonne qu'il obtiendrait plus de vues là-bas.

Bien que je sois entièrement d'accord pour dire que le contrôle des sources est la bonne façon de le faire, je comprends également que tous les environnements ne sont pas suffisamment disciplinés pour s'appuyer uniquement sur cela (le cas échéant), et que parfois des changements doivent être apportés directement pour conserver l'application. en cours d'exécution, enregistrez un client, qu'avez-vous.

Vous pouvez utiliser un déclencheur DDL pour conserver toutes les révisions dans une table dans une base de données distincte (et bien sûr sauvegarder cette base de données fréquemment). En supposant que vous ayez une base de données utilitaire:

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)
);

Maintenant dans votre base de données, prenons d'abord ce que nous appellerons "contrôle initial" - la version actuelle des procédures stockées:

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;

Maintenant, pour capturer les modifications ultérieures, ajoutez un déclencheur DDL à la base de données:

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

Au fil du temps, il deviendra facile de voir et de comparer les modifications apportées aux procédures, de voir de nouvelles procédures s'ajouter au système, de voir les procédures abandonnées et d'avoir une bonne idée de la personne à qui parler de l'un de ces événements.

Plus d'informations ici:

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

Je ne pense pas qu'il existe un moyen de garder automatiquement votre code source SQL sous contrôle de version. Je veux dire avec les outils Native SQL Server. Je pense que vous pourriez finir par utiliser git ou svn, mais la meilleure solution pour moi était d'acheter le contrôle de source de Red Gate pour garder les bases de données (et les procédures stockées) sous contrôle de version.