Remarque: je ne demande pas de contrôle de version complet.
Existe-t-il un moyen de conserver automatiquement un historique des procédures stockées sur SQL Server.
Semblable à 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 https://stackoverflow.com/questions/14522224/how-to-keep-history-of-sql-server-stored-procedure-revisions d'abord parce que je pense qu'il obtiendrait plus de vues Là.
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 Red Gate's Source Control pour garder les bases de données (et les procédures stockées) sous contrôle de version.