Nous choisissons de script tout, et cela inclut toutes les procédures stockées et les changements de schéma. Aucun outil wysiwyg, ni aucun programme de "synchronisation" fantaisiste n'est nécessaire.
Les modifications de schéma sont faciles, il suffit de créer et de maintenir un fichier unique pour cette version, comprenant toutes les modifications de schéma et de données. Cela devient votre script de conversion de la version x à x+1. Vous pouvez ensuite l'exécuter par rapport à une sauvegarde de production et l'intégrer dans votre " build quotidien " pour vérifier qu'il fonctionne sans erreur. Notez qu'il est important de ne pas modifier ou supprimer le schéma déjà écrit / le sql de chargement de données car vous pouvez finir par casser tout sql écrit plus tard.
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
Pour les procédures stockées, nous choisissons un seul fichier par sproc, et il utilise le formulaire drop/create. Toutes les procédures stockées sont recréées lors du déploiement. L'inconvénient est que si une modification a été effectuée en dehors du contrôle de la source, la modification est perdue. En même temps, c'est vrai pour tout code, mais vos DBA'a doivent en être conscients. Cela empêche vraiment les personnes extérieures à l'équipe de manipuler vos procédures stockées, car leurs modifications sont perdues lors d'une mise à niveau.
En utilisant Sql Server, la syntaxe ressemble à ceci :
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
La seule chose qui reste à faire est d'écrire un programme utilitaire qui rassemble tous les fichiers individuels et crée un nouveau fichier avec l'ensemble des mises à jour (comme un seul script). Faites-le en ajoutant d'abord les changements de schéma puis en récurant la structure du répertoire et en incluant tous les fichiers de procédures stockées.
L'avantage de tout scripter, c'est que vous deviendrez bien meilleur pour lire et écrire du SQL. Vous pouvez également rendre ce processus plus élaboré, mais il s'agit du format de base pour contrôler le code source de tout le SQL sans logiciel spécial.
addendum : Rick a raison de dire que vous perdrez les permissions sur les procédures stockées avec DROP/CREATE, donc vous pouvez avoir besoin d'écrire un autre script va réactiver les permissions spécifiques. Cette permission script serait la dernière à être exécutée. Notre expérience a révélé plus de problèmes avec la sémantique ALTER par rapport à DROP/CREATE. YMMV
