Comment conserver les procédures stockées et autres scripts dans le référentiel SVN/Autre ?

Question

Quelqu'un peut-il fournir des exemples réels sur la meilleure façon de conserver les fichiers de script pour les vues, les procédures stockées et les fonctions dans un référentiel SVN (ou autre).

Évidemment, une solution consiste à avoir les fichiers de script pour tous les différents composants dans un répertoire ou plus quelque part et à utiliser simplement TortoiseSVN ou similaire pour les conserver dans SVN. Ensuite, chaque fois qu'une modification doit être apportée, je charge le script dans Management Studio, etc. .Je ne veux pas vraiment ça.

Ce que je préférerais vraiment, c'est une sorte de script batch que je peux exécuter périodiquement (tous les soirs ?) qui exporterait toutes les procédures / vues stockées, etc. qui ont changé au cours d'une période donnée, puis les validerait dans SVN.

Des idées ?

Answer 1

Il me semble que vous ne souhaitez pas utiliser correctement le contrôle de révision.

De toute évidence, une solution consiste à avoir les fichiers de script pour tous les différents composants d'un répertoire ou plus quelque part et simplement en utilisant TortoiseSVN ou autres pour les garder dans SVN

C'est ce qu'il faut faire.Vous auriez votre copie locale sur laquelle vous travaillez (développement de nouveaux, peaufinage d'anciens, etc.) et à mesure que des composants/procédures/etc. individuels seraient terminés, vous les engageriez individuellement jusqu'à ce que vous deviez recommencer le processus.

Valider du code à moitié terminé simplement parce que cela fait « X » depuis sa dernière validation est bâclé et garantit de causer des problèmes à toute autre personne utilisant le référentiel.

Answer 2

Je trouve préférable de traiter les procédures stockées comme n'importe quel autre code compilable :Le code réside dans le référentiel, vous l'extraire pour apporter des modifications et le charger dans votre outil de développement pour compiler ou déployer le code.

Answer 3

Vous pouvez créer un fichier batch et le planifier :

• supprimez le contenu de votre répertoire de scripts
• en utilisant quelque chose comme ExporterSQLScript pour exporter tous les objets vers un/des scripts
• validation svn

Veuillez noter:Même si vous aurez les objets sous contrôle de source, vous n'aurez pas les données ou leur progression (est-ce un champ renommé, ou 1 nouveau champ et 1 supprimé ?).

Cette approche convient parfaitement pour conserver l’historique des modifications.Mais, bien sûr, vous ne devriez jamais vous engager automatiquement dans la « version de production » (sauf si vous aimez les versions cassées).

Même si vous ne l'avez pas demandé :Cette approche ne produira pas non plus un ensemble de scripts qui mettront à niveau une base de données actuelle.Vous n'aurez que des scripts de création initiaux.L'enregistrement de la progression des données et la création de scripts de mise à niveau vont au-delà des systèmes de contrôle de source de base.

Answer 4

je recommanderais porte rouge SQL Compare pour cela - il vous permet de comparer les versions de bases de données et de générer des scripts de modification - il est également assez facilement scriptable.

Answer 5

Sur la base de votre question développée, vous souhaitez vraiment utiliser les déclencheurs DDL.Vérifier Cet article qui détaille comment créer un système de journal des modifications pour votre base de données.

Answer 6

Cependant, je ne suis pas sûr de votre fourchette de prix Fantôme de base de données pourrait être une option pour vous.

Je ne travaille pas pour cette entreprise (ni ne possède le produit), mais dans mes recherches sur le même problème, ce produit semblait assez prometteur.

Answer 7

J'aurais dû être un peu plus descriptif.La base de données en question est destinée à un système ERP interne et nous n'avons donc pas beaucoup de versions de notre base de données, juste Production/Test/Développement.Lorsque nous avons fait une demande de modification, une nouvelle fonctionnalité sophistiquée ou quelque chose du genre, nous exécutons simplement un script ou une série de scripts pour mettre à jour les procédures en question sur la base de données de test, si tout va bien, alors nous faisons de même avec Production.

Je ne recherche donc pas vraiment un script de schéma complet en soi, juste quelque chose qui permet de suivre les différentes modifications apportées aux procédures stockées au fil du temps.Par exemple, PROCESS_INVOICE fait des choses.Il est mis à jour de manière mineure en mars.Quelque temps plus tard, disons en mai, on découvre que dans de rares cas, les clients sont facturés deux fois (ou dans un autre cas fou).J'aimerais pouvoir voir ce qui est arrivé au fil du temps à cette procédure.Actuellement, la façon dont l'environnement de développement est configuré ici, je ne l'ai pas, ce que j'essaie de changer.

Answer 8

Je peux recommander DBPro qui fait partie de Visual Studio Team Edition.Je l'utilise depuis quelques mois pour stocker toutes les parties de la base de données dans Team Foundation Server ainsi que pour le déploiement et les comparaisons de bases de données, etc.

Bien sûr, comme quelqu’un l’a mentionné, cela dépend de votre environnement et de votre fourchette de prix.

Answer 9

J'ai écrit un utilitaire pour vider toutes les parties pertinentes de ma base de données dans une structure de répertoires sur laquelle j'utilise SVN.Je n'ai jamais eu l'idée d'essayer de l'intégrer dans le Manager mais, si cela vous intéresse, c'est ici : http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

C'est gratuit et, comme je l'utilise régulièrement, vous savez que tous les bugs sont rapidement corrigés.

Answer 10

Vous pouvez toujours essayer d'intégrer SourceSafe à SQL Server.Voici un démarrage rapide : lien .Pour travailler avec, vous devez disposer de Management Studio Developers Edition.