Contrôle de version avec SQL Server


14

Je démarre un nouveau projet et j'utilise SVN (avec Tortoise) comme système de contrôle de version. Je me demandais s'il était possible de maintenir également une base de données SQL Server en utilisant le même système.

Je voudrais mettre à jour mes tables / fonctions / vues / procs / déclencheurs / etc. mais pas mes données car ce seront toutes des données de test de toute façon. Je ne sais pas vraiment comment configurer cela. Je suis tombé sur quelques options, mais je voudrais savoir s'il en manquait, et s'il y a peut-être un guide ou quelque chose pour m'aider à m'en servir.

J'ai vu et entendu parler de Red Gate, mais je suis à la recherche de quelque chose de gratuit (ou du moins très peu coûteux). Je sais que je pourrais toujours écrire quelque chose moi-même, mais je n'essaie pas vraiment d'y consacrer du temps.

Une chose que j'ai rencontrée était un package open source appelé ScriptDB4Svn . Quelqu'un a-t-il déjà utilisé ça avant? Est-ce bien? Peut-il faire les choses dont j'ai besoin et est-il assez simple de se configurer?


1
Has anyone used this before? Is it good? Can it do the things I need it to do and is it pretty simple to get setup?Pourquoi avez-vous peur de l'essayer par vous-même? Saisissez-le et jouez.
yannis

@YannisRizos - Je le ferai certainement si je n'obtiens pas trop de réponses, je voulais simplement essayer de gagner du temps et voir si quelqu'un avait déjà travaillé avec, ou si quelqu'un avait essayé et testé quelque chose dès le départ qui correspondent à mes besoins afin que je puisse gagner du temps d'expérimentation.

Je viens de remarquer à quel point vous êtes nouveau ici. Les programmeurs SE ne sont pas un bon endroit pour poser des questions juste pour gagner du temps, nous attendons vraiment de vous que vous fassiez des choses comme ça, c'est -à- dire que vous fassiez vos propres recherches avant de poser . Ou, alternativement, demandez dans le chat (mais ne vous attendez pas à des réponses solides). Cela dit, cela n'a vraiment pas d'importance car cette dernière phrase n'est pas votre question principale, qui est en fait une très bonne question (et correctement étiquetée, c'est rare pour les nouveaux utilisateurs, bravo!).
yannis

@YannisRizos - merci. Je vais sauter dans le chat pour voir si je peux obtenir des commentaires sur ScriptDB4Svn, et revenir ici pour toute mise à jour de la question centrale. Edit: On dirait que je ne peux pas discuter avant d'avoir 20 représentants. Oh bien, patience je suppose.

Réponses:


2

Techniquement, vous n'avez même pas besoin d'un outil, vous pouvez directement scripter les objets et les archiver dans le contrôle de code source. C'est un peu plus de travail sans l'outil, mais c'est certainement réalisable.

BTW: J'ai utilisé l'outil RedGate et il est assez élégant et vaut de l'argent.


Donc, fondamentalement, je ferais mon travail dans Management Studio, puis j'exporterais les scripts dans le répertoire SVN, et le ferais chaque fois que j'y travaillerais (en remplaçant les anciens à chaque exportation)? Je suppose que cela fonctionnerait. Cela garderait la fonctionnalité SVN de pouvoir revenir en arrière et tout, mais oui, ce serait une sorte de tracas. Je vais peut-être consulter les tarifs RedGate et voir si cela en vaut la peine pour moi.

@Scott - La méthode manuelle peut fonctionner, il vous suffit de penser différemment à votre développement SQL. Les versions scriptées des objets sont celles "officielles" et celle de SQL n'est qu'une version compilée de celui-ci. Tout comme votre code source.
JohnFx

J'ai décidé de faire les choses manuellement, et éventuellement d'implémenter un script en utilisant l'aide dans les liens fournis par Mike Nakis, mais pour le moment, je vais simplement utiliser l'interface graphique intégrée dans Management Studio pour exporter les scripts de création de base de données lorsque j'aurai terminé fonctionne, vérifiez-les et laissez SVN les garder versionnés de cette façon. Depuis que j'ai décidé de faire les choses manuellement, vous obtenez la réponse pour souligner que je n'ai pas vraiment besoin d'un outil pour faire ce genre de choses :)

1

Il semble que vous ayez une configuration principalement Microsoft. Vous pouvez jeter un œil aux projets de base de données (anciennement DataDude). Ils transforment essentiellement T-SQL en un langage de première classe dans Visual Studio; vous pouvez:

  • Compiler des projets - il ne crée pas simplement un script final, il s'assure que les noms d'objets, etc. existent.
  • Effectuez une analyse de code statique - par exemple, en vous assurant que vous vous référez toujours aux objets en incluant leur schéma (par exemple, [dbo]dans la plupart des cas) pour cette belle augmentation de 30% des performances.
  • Créez des scripts diff en lui faisant comparer différentes versions du projet.
  • Mettez à jour votre projet à partir d'une base de données ou d'un script (reverse engineering).
  • Intellisense.
  • Il n'y a pas d'outils de création de diagrammes.

Ils unifient également votre code et le code de votre base de données sous le contrôle des sources. Si vous l' homme-up et l' écriture de vos objets de base de données ( au lieu d'utiliser des outils Davinci dans SSMS) vous atterrissez également à l' aide d' un IDE - ce qui est agréable.


0

Vous pouvez utiliser Rails. Rails a un concept de migration de base de données que vous pouvez appliquer ou annuler. D'après mon expérience, c'est la meilleure façon de mettre à jour une base de données. Vous vérifiez ces fichiers de migration dans SVN.

Dans mon projet actuel, nous ne développons pas l'application dans Ruby, mais nous utilisons toujours Rails pour gérer la base de données. Je ne le ferais pas autrement.


Avez-vous des guides pour expliquer cela un peu plus et aller dans la mise en place de quelque chose comme ça?

En fait, ce n'est pas une très bonne idée d'utiliser Rails avec les technologies .NET.
altern

Chapitre sur les migrations Rails ( guides.rubyonrails.org/migrations.html ). Cela devrait être suffisant pour vous aider à démarrer et vous donner toutes les informations nécessaires pour expliquer pourquoi c'est une bonne idée. @altern - puisque vous utilisez simplement Rails pour manipuler et versionner la base de données, cela devrait avoir un impact sur les technologies .NET. Vous pouvez accéder à la base de données et l'utiliser de la même manière que si vous n'utilisiez pas de rails. Cela ne me dérangerait pas de voir des références à vos préoccupations. IronRuby n'est-il pas une implémentation .Net de Ruby et Rails?
Vinnie

> IronRuby n'est-il pas une implémentation .Net de Ruby et Rails? IronRuby est une implémentation .NET de Ruby . Je ne suis pas sûr que Rails fonctionne correctement sur IronRuby. Mon argument général contre l'utilisation de Rails à des fins de gestion de versions db est que Ruby et les technologies associées (RoR, migratinos) ont une courbe d'apprentissage assez abrupte, en particulier pour une tâche aussi simple que la gestion de versions db. Vous pouvez l'utiliser à d'autres fins, pas seulement pour les migrations. Sinon, cela augmentera simplement la complexité du projet sans beaucoup d'effets positifs.
alternance le

0

Cela a déjà été discuté sur stackoverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

En outre, cet article externe fournit des informations supplémentaires http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated ainsi qu'un exemple de code sous la forme d'une application Windows.

Puisque ce que vous voulez faire est quelque chose que j'ai fait moi-même pour MS Access, je vais vous dire ce que j'ai fait au cas où cela vous donnerait quelques idées: j'ai écrit un module appelé Ado2Xml qui convertit le schéma et les données de tout ADO -Base de données accessible en xml, et inversement. Cependant, il ne connaît que les tables et les vues; pas de procédures stockées, pas de déclencheurs, rien. Quoi qu'il en soit, dans votre cas, ce module est remplacé par l'outil que vous trouverez probablement qui fait ce que vous voulez avec MS-SQL. Ainsi, à chaque lancement de mon application, il compare l'horodatage de la base de données à l'horodatage du fichier xml enregistré; si le fichier xml est plus récent, il détruit la base de données et appelle Ado2Xml pour le recréer à partir du fichier xml. Lorsque mon application se termine, elle fait l'inverse: elle invoque Ado2Xml pour exporter la base de données dans le fichier xml. Réellement, les objets ADO qui extraient le schéma de base de données sont pour une raison terriblement lente, ce qui entraîne un certain temps pour le processus d'exportation. Donc, afin d'éviter d'avoir à attendre à chaque fois que mon application se termine et que Visual Studio passe de la disposition de débogage à la disposition d'édition, juste avant la fin, mon application lance une application externe pour effectuer l'exportation, afin qu'elle puisse se terminer immédiatement.


Les deux liens que vous avez fournis sont quelque chose que je suis probablement intéressé à installer moi-même, donc je peux essentiellement automatiser les étapes manuelles que je fais en ce moment. Merci pour ça!

0

Oui, j'ai utilisé un outil similaire (développé en interne) sur un projet précédent. Il scripterait toutes les tables, vues, sprocs, déclencheurs, etc. dans des fichiers .sql individuels. Ensuite, nous avons eu un script qui s'exécutait tous les soirs pour «valider» que tout dans notre base de données «développement» se reflétait dans le contrôle des sources.

Ainsi, le flux de travail normal consiste à modifier votre code, à modifier les tables et les sprocs correspondants dans la base de données de développement selon les besoins, puis à exécuter l'outil que nous avions qui actualiserait tous les fichiers .sql scriptés. Vous devriez alors tout enregistrer en même temps.

Le problème était que si vous oubliez d'exécuter l'outil, le code "fonctionnerait" (et les tests unitaires passeraient) car la base de données était "correcte", mais les nouveaux sprocs / tables ne seraient pas le contrôle de code source.

Donc, tous les soirs, nous avons un script qui a fait une vérification du code source, puis rand l'outil pour rafraîchir tous les scripts. S'il y avait une différence, cela signifie que quelqu'un a oublié de vérifier ses modifications et une notification par e-mail a été générée. C'était essentiellement un moyen de s'assurer que nous n'oublions pas de garder le contrôle de la source à jour.

C'était un peu ennuyeux car il était difficile de travailler sur des changements qui s'étalaient sur plusieurs jours, mais c'était mieux que de ne rien avoir ...


Pouvez-vous nous en dire plus Then, we had a script that ran every night to "validate" that everything in our "development" database was reflected in source control.? Merci pour votre réponse.

@Scott: J'ai modifié la réponse pour inclure un peu plus de détails.
Dean Harding
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.