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


22

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.


Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .
Paul White dit GoFundMonica

Réponses:


31

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/


2
+1 La façon la plus simple et native de le faire. Je suppose que c'est la réponse que le PO recherchait.
Thomas Stringer

Oui, ce sera la solution pour le problème d'OP.
Marian

J'adore cette réponse, car une fois que vous le faites, vous obtenez une version automatique sans frais supplémentaires. Je suis d'accord que ce n'est pas la même chose que le contrôle de source, mais c'est un filet de sécurité précieux qui ne doit pas être ignoré.
Daniel Williams,

2

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.


1
Bien sûr, un déclencheur DDL peut le faire sans avoir besoin d'outils tiers (voir ma réponse). Bien sûr, le contrôle des sources offre un contrôle et un audit beaucoup plus importants, et les outils tiers auront beaucoup plus de fonctionnalités que vous ne voudrez l'écrire vous-même, mais ils n'ont aucun moyen de vous protéger contre les changements directs - en d'autres termes, ils comptent sur tout le monde obéissant au protocole de contrôle des sources (ce qui n'est pas toujours faisable).
Aaron Bertrand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.