Existe-t-il un système de contrôle de version pour les modifications de la structure de la base de données?

Je rencontre souvent le problème suivant.

Je travaille sur certaines modifications d'un projet qui nécessitent de nouvelles tables ou colonnes dans la base de données. Je fais les modifications de la base de données et continue mon travail. Habituellement, je me souviens de noter les modifications afin qu'elles puissent être répliquées sur le système en direct. Cependant, je ne me souviens pas toujours de ce que j'ai changé et je ne me souviens pas toujours de l'écrire.

Donc, je fais une poussée vers le système live et j'obtiens une grosse erreur évidente qu'il n'y a pas NewColumnX, euh.

Indépendamment du fait que ce n'est peut-être pas la meilleure pratique dans cette situation, existe-t-il un système de contrôle de version pour les bases de données? Je me fiche de la technologie de base de données spécifique. Je veux juste savoir s'il en existe un. Si cela fonctionne avec MS SQL Server, tant mieux.

Dans Ruby on Rails, il existe un concept de migration - un script rapide pour modifier la base de données.

Vous générez un fichier de migration, qui a des règles pour augmenter la version de base de données (comme l'ajout d'une colonne) et des règles pour rétrograder la version (comme la suppression d'une colonne). Chaque migration est numérotée et un tableau garde la trace de votre version actuelle de la base de données.

Pour migrer vers le haut , vous exécutez une commande appelée "db: migrate" qui examine votre version et applique les scripts nécessaires. Vous pouvez migrer vers le bas de la même manière.

Les scripts de migration eux-mêmes sont conservés dans un système de contrôle de version - chaque fois que vous modifiez la base de données, vous archivez un nouveau script, et tout développeur peut l'appliquer pour apporter sa base de données locale à la dernière version.

Je suis un peu old-school, en ce sens que j'utilise des fichiers source pour créer la base de données. Il existe en fait 2 fichiers - project-database.sql et project-updates.sql - le premier pour le schéma et les données persistantes, et le second pour les modifications. Bien sûr, les deux sont sous contrôle de la source.

Lorsque la base de données change, je mets d'abord à jour le schéma principal dans project-database.sql, puis je copie les informations pertinentes dans le project-updates.sql, par exemple les instructions ALTER TABLE. Je peux ensuite appliquer les mises à jour à la base de données de développement, tester, itérer jusqu'à ce que cela soit bien fait. Ensuite, archivez les fichiers, testez à nouveau et appliquez à la production.

De plus, j'ai généralement une table dans la base de données - Config - telle que:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Ensuite, j'ajoute ce qui suit à la section mise à jour:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Le db_versionseul est modifié lorsque la base de données est recréée, et le db_revisionme donne une indication de la distance entre la base de données et la ligne de base.

Je pouvais conserver les mises à jour dans leurs propres fichiers séparés, mais j'ai choisi de les écraser tous ensemble et d'utiliser le copier-coller pour extraire les sections pertinentes. Un peu plus de ménage est nécessaire, c'est-à-dire, supprimez ':' de $ Revision 1.1 $ pour les figer.

MyBatis (anciennement iBatis) dispose d'un outil de migration de schéma , à utiliser en ligne de commande. Il est écrit en java mais peut être utilisé avec n'importe quel projet.

Pour parvenir à une bonne pratique de gestion du changement de base de données, nous devons identifier quelques objectifs clés. Ainsi, le système de migration de schéma MyBatis (ou MyBatis Migrations en abrégé) cherche à:

• Travaillez avec n'importe quelle base de données, nouvelle ou existante
• Tirer parti du système de contrôle de source (par exemple Subversion)
• Permettre aux développeurs ou équipes simultanés de travailler de manière indépendante
• Permettre des conflits très visibles et facilement gérables
• Permettre la migration vers l'avant et vers l'arrière (évoluer, dévolution respectivement)
• Rendre l'état actuel de la base de données facilement accessible et compréhensible
• Activer les migrations malgré les privilèges d'accès ou la bureaucratie
• Travaillez avec n'importe quelle méthodologie
• Encourage les bonnes pratiques cohérentes

Redgate a un produit appelé SQL Source Control . Il s'intègre à TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce et Git.

Je recommande fortement SQL delta . Je l'utilise juste pour générer les scripts de différence lorsque j'ai fini de coder ma fonctionnalité et de vérifier ces scripts dans mon outil de contrôle de source (Mercurial :))

Ils ont à la fois une version serveur SQL et Oracle.

Je me demande que personne n'ait mentionné l'outil open source liquibase qui est basé sur Java et devrait fonctionner pour presque toutes les bases de données prenant en charge jdbc. Par rapport aux rails, il utilise xml à la place de ruby ​​pour effectuer les changements de schéma. Bien que je n'aime pas xml pour les langages spécifiques à un domaine, l'avantage très cool de xml est que liquibase sait comment annuler certaines opérations comme

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Donc, vous n'avez pas besoin de gérer cela de votre propre chef

Les instructions SQL pures ou les importations de données sont également prises en charge.

La plupart des moteurs de base de données doivent prendre en charge le vidage de votre base de données dans un fichier. Je sais que MySQL le fait, de toute façon. Ce sera juste un fichier texte, vous pouvez donc le soumettre à Subversion ou à tout ce que vous utilisez. Il serait également facile d'exécuter un diff sur les fichiers.

Si vous utilisez SQL Server, il serait difficile de battre Data Dude (aka l'édition de base de données de Visual Studio). Une fois que vous avez compris, faire une comparaison de schéma entre votre version contrôlée par la source de la base de données et la version en production est un jeu d'enfant. Et avec un clic, vous pouvez générer votre diff DDL.

Il y a une vidéo d' instructions sur MSDN qui est très utile.

Je connais DBMS_METADATA et Toad, mais si quelqu'un pouvait trouver un Data Dude pour Oracle, la vie serait vraiment douce.

Demandez à vos instructions de création de table initiales dans le contrôleur de version, puis ajoutez des instructions alter table, mais ne modifiez jamais les fichiers, mais modifiez simplement les fichiers idéalement nommés séquentiellement, ou même sous la forme d'un «ensemble de modifications», afin que vous puissiez trouver toutes les modifications pour un déploiement particulier.

La partie la plus difficile que je puisse voir est le suivi des dépendances, par exemple, pour une table de déploiement particulière, B peut avoir besoin d'être mise à jour avant la table A.

Pour Oracle, j'utilise Toad , qui peut vider un schéma dans un certain nombre de fichiers discrets (par exemple, un fichier par table). J'ai quelques scripts qui gèrent cette collection dans Perforce, mais je pense que cela devrait être facilement faisable dans n'importe quel système de contrôle de révision.

Jetez un œil au package oracle DBMS_METADATA.

En particulier, les méthodes suivantes sont particulièrement utiles:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Une fois que vous êtes familiarisé avec leur fonctionnement (assez explicite), vous pouvez écrire un script simple pour vider les résultats de ces méthodes dans des fichiers texte qui peuvent être placés sous contrôle de code source. Bonne chance!

Je ne sais pas s'il y a quelque chose d'aussi simple pour MSSQL.

J'écris mes scripts de publication de base de données en parallèle avec le codage et je garde les scripts de publication dans une section spécifique au projet dans SS. Si j'apporte une modification au code qui nécessite une modification de la base de données, je mets à jour le script de publication en même temps. Avant la publication, j'exécute le script de publication sur une base de données de développement propre (structure copiée à partir de la production) et j'effectue mes tests finaux dessus.

Je l'ai fait par intermittence pendant des années - en gérant (ou en essayant de gérer) les versions de schéma. Les meilleures approches dépendent des outils dont vous disposez. Si vous pouvez obtenir l'outil "Schema Manager" de Quest Software, vous serez en pleine forme. Oracle a son propre outil de qualité inférieure également appelé "Schema Manager" (déroutant beaucoup?) Que je ne recommande pas.

Sans outil automatisé (voir d'autres commentaires ici sur Data Dude), vous utiliserez directement des scripts et des fichiers DDL. Choisissez une approche, documentez-la et suivez-la rigoureusement. J'aime avoir la possibilité de recréer la base de données à tout moment, donc je préfère avoir un export DDL complet de la base de données entière (si je suis le DBA), ou du schéma développeur (si je suis dans le produit -Mode de développement).

PLSQL Developer, un outil de All Arround Automations, dispose d'un plugin pour les référentiels qui fonctionne correctement (mais pas très bien) avec Visual Source Safe.

Sur le Web:

Le plug-in de contrôle de version fournit une intégration étroite entre l'IDE de développement PL / SQL >> et tout système de contrôle de version prenant en charge la spécification d'interface Microsoft SCC. >> Cela inclut les systèmes de contrôle de version les plus populaires tels que Microsoft Visual SourceSafe, >> Merant PVCS et MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio vous permet d'inverser le schéma de votre base de données dans l'outil et vous pouvez ensuite le comparer aux bases de données en direct.

Exemple: inversez votre schéma de développement dans ER Studio - comparez-le à la production et il listera toutes les différences. Il peut programmer les modifications ou simplement les appliquer automatiquement.

Une fois que vous avez un schéma dans ER Studio, vous pouvez soit enregistrer le script de création, soit l'enregistrer en tant que binaire propriétaire et l'enregistrer dans le contrôle de version. Si vous souhaitez revenir à une version antérieure du schéma, vérifiez-le et transférez-le sur votre plate-forme db.

Il existe un "framework de migration de base de données" PHP5 appelé Ruckusing. Je ne l'ai pas utilisé, mais les exemples montrent l'idée, si vous utilisez le langage pour créer la base de données au fur et à mesure des besoins, vous n'avez qu'à suivre les fichiers source.

Vous pouvez utiliser les outils de données Microsoft SQL Server dans Visual Studio pour générer des scripts pour des objets de base de données dans le cadre d'un projet SQL Server. Vous pouvez ensuite ajouter les scripts au contrôle de code source à l'aide de l'intégration de contrôle de code source intégrée à Visual Studio. En outre, les projets SQL Server vous permettent de vérifier les objets de base de données à l'aide d'un compilateur et de générer des scripts de déploiement pour mettre à jour une base de données existante ou en créer une nouvelle.

Nous avons utilisé MS Team System Database Edition avec un assez bon succès. Il s'intègre au contrôle de version TFS et à Visual Studio de manière plus ou moins transparente et nous permet de gérer facilement les processus stockés, les vues, etc. La résolution des conflits peut être pénible, mais l'historique des versions est complet une fois terminé. Par la suite, les migrations vers l'assurance qualité et la production sont extrêmement simples.

Il est juste de dire que c'est un produit de la version 1.0, cependant, et n'est pas sans quelques problèmes.

Schema Compare for Oracle est un outil spécialement conçu pour migrer les modifications de notre base de données Oracle vers une autre. Veuillez visiter l'URL ci-dessous pour le lien de téléchargement, où vous pourrez utiliser le logiciel pour un essai entièrement fonctionnel.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

En l'absence d'un VCS pour les changements de table, je les ai consignés dans un wiki. Au moins, je peux voir quand et pourquoi cela a été changé. C'est loin d'être parfait car tout le monde ne le fait pas et nous avons plusieurs versions de produits en cours d'utilisation, mais mieux que rien.

Je recommanderais l'une des deux approches. Tout d'abord, investissez dans PowerAMC de Sybase. Edition pour entreprise. Il vous permet de concevoir des modèles de données physiques, et bien plus encore. Mais il est livré avec un référentiel qui vous permet d'archiver vos modèles. Chaque nouveau check-in peut être une nouvelle version, il peut comparer n'importe quelle version à n'importe quelle autre version et même à ce qui est dans votre base de données à ce moment-là. Il présentera ensuite une liste de toutes les différences et demandera laquelle doit être migrée… puis il construira le script pour le faire. Ce n'est pas bon marché mais c'est une bonne affaire à deux fois le prix et son retour sur investissement est d'environ 6 mois.

L'autre idée est d'activer l'audit DDL (fonctionne dans Oracle). Cela créera un tableau avec chaque modification que vous apportez. Si vous interrogez les modifications à partir de l'horodatage où vous avez déplacé pour la dernière fois les modifications de votre base de données vers prod vers maintenant, vous aurez une liste ordonnée de tout ce que vous avez fait. Quelques clauses where pour éliminer les changements à somme nulle comme create table foo; suivi de drop table foo; et vous pouvez facilement créer un script de mod. Pourquoi garder les changements dans un wiki, c'est le double du travail. Laissez la base de données les suivre pour vous.

Deux recommandations de livres: "Refactoring Databases" par Ambler et Sadalage et "Agile Database Techniques" par Ambler.

Quelqu'un a mentionné les migrations Rails. Je pense qu'ils fonctionnent très bien, même en dehors des applications Rails. Je les ai utilisés sur une application ASP avec SQL Server dont nous étions en train de passer à Rails. Vous vérifiez les scripts de migration eux-mêmes dans le VCS. Voici un article de Pragmatic Dave Thomas sur le sujet.