Génération de scripts de base de données pour le versioning de base de données SQL Server

Question

Dans le cadre de la programmation et du versioning responsables, je voudrais commencer à version mes changements de base de données, d'autant plus que je me développe sur mon instance de base de données, puis en le déplaçant vers la production. Je n'ai trouvé rien qui a vraiment du sens pour moi sur la façon de procéder. J'utilise Visual Studio 2010 Pro comme IDE. Existe-t-il un document qui rend ce processus simple et capable de détecter les modifications de la base de données avec une facilité relative? Ou que dois-je changer dans mon flux de travail pour faciliter cela?

Answer 1

Une façon dont j'ai réussi ce genre de chose dans le passé, est via Contrôle de la source SQL. Visual Studio ne vous offre pas cette fonctionnalité.

Alternativement, vous pouvez utiliser SSMS pour générer les scripts de base de données pour vous et l'enregistrer en tant que fichier; Ensuite, vous pouvez vérifier le script. Vous choisiriez si vous générez l'intégralité du script DB dans un seul fichier ou si vous le faites sur une base d'objet. La partie de synchronisation devra être effectuée par vous en exécutant vos scripts en production. En conclusion cauchemar total.

Redgate propose également SQL Compare, ce qui est idéal pour la synchronisation des bases de données. Jetez un œil à leurs produits si vous ou votre entreprise pouvez vous le permettre.

Answer 2

Nous utilisons notre propre solution de base de données en interne qui apporte tous les outils requis pour le versioning DB approprié. Bien que je réalise que ce n'est peut-être pas une solution parfaite pour tout le monde, je vous invite à y jeter un œil (c'est open-source): BSN ModuleStore

L'aspect du versioning est le suivant: L'outil peut scripter le SQL semi-automatiquement, et il reformate le code source pour être dans un format uniforme. Les fichiers seront donc toujours identiques pour la même source, peu importe quand et par qui quelque chose a été scénarisé; Cela fonctionne donc bien avec les systèmes de contrôle des sources non verrouillées (en particulier SVN, GIT ou Mercurial).

Le Reformat met toutes les déclarations sous la même forme (par exemple, des mots clés facultatifs tels que AS, INNER, OUTER etc. sont traités), les scripts tout au schéma "DBO" (même s'il était dans un autre), met tous les identifiants dans les accolades carrées ([something]), Uppernases Tous les mots réservés, fait l'indentation, etc.

Outre le versioning, la partie d'exécution de l'outil peut diffuser la base de données en cours d'exécution et les scripts de création (code source de base de données) et appliquer automatiquement les mises à jour pour toutes les modifications non destructeurs (par exemple, les index, les contraintes, les vues, les procédures stockées, les déclencheurs, les types personnalisés, Nouvelles tables, etc.). Les changements destructifs doivent être scénarisés manuellement (changements de table qui nécessitent alors généralement des transformations de données). Le runtime s'assurera que toutes les mises à jour sont effectuées dans une transaction et un retour en arrière si la base de données résultante ne correspond pas aux scripts de création, donc vous obtenez la sécurité de savoir que la base de données est exactement sur la version requise par l'application, même si elle a été falsifié manuellement.

De plus, plusieurs "modules" peuvent être utilisés dans une seule base de données. Chaque module est stocké sous forme de schéma et indépendant des autres schémas, ce qui permet d'ajouter ou de supprimer des modules d'une seule base de données, et d'éviter la nécessité de créer plusieurs bases de données pour différentes parties de l'application. De plus, l'utilisation de schémas pour ce faire garantit qu'il n'y a pas de collision de nom.

Il peut être utile de noter que l'ensemble d'outils n'a aucune dépendance au SMO, il est autonome.

Answer 3

Enregistrez vos scripts de base de données sur SVN. Voici la référence Comment utiliser SVN Tortoise

OU

Enregistrez votre script de base de données sur VSS. Voici la référence Qu'est-ce que VSS? Comment pouvons-nous l'utiliser?

Dans les deux cas, vous pouvez garder une trace des modifications apportées afin qu'à l'avenir, vous puissiez vérifier l'historique qui dans la forme de versions.

Vous pouvez également utiliser le produit Red Gate

ÉDITER

Comment retirez-vous ce qui a changé?

Utilisez la fonction de comparaison pour vérifier les modifications apportées dans les versions précédentes.

Comment appliquer les modifications au serveur de base de données en direct?

Téléchargez le dernier fichier depuis le serveur.

J'espère que vous n'utilisez pas les instructions DROP pour la table dans votre script consolidé. Car il supprimera tous les enregistrements du tableau.

Les instructions de dépôt auront lieu pour le pro, la vue, la fonction stockée, etc.

Veuillez noter que vous devez exécuter le dernier fichier de script de base de données complet sur le serveur de production avec des plans d'action mentionnés ci-dessous

1. Remove Drop Statement for Schema DDL
2. Add Drop/Create Statements for Stored Proc/Views
3. Include Alter statements DML of schema.

J'espère que cela vous aidera certainement.