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

Je rencontre souvent le problème suivant.

Je travaille sur certaines modifications à 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 d'écrire les changements afin qu'ils puissent être répliqués 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 un push sur le système live et j'obtiens une grosse erreur évidente qu'il n'y a pas de NewColumnX , pouah.

Indépendamment du fait que cela ne soit pas la meilleure pratique pour cette situation, existe-t-il un système de contrôle de version pour les bases de données? Je ne me soucie pas 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, alors c'est génial.

0
ajouté édité
Vues: 12
Selon nos conseils sur le sujet , Certaines questions sont encore hors sujet, même si elles correspondent à une question. des catégories énumérées ci-dessus: ... Les questions nous demandant de recommander ou de trouver un livre, un outil, une bibliothèque de logiciels, un tutoriel ou autre ressource hors site sont hors sujet ... "
ajouté l'auteur Robert Columbia, source

19 Réponses

Dans ruby on Rails, il y a un concept de migration - un script rapide pour changer le base de données.

Vous générez un fichier de migration, qui comporte des règles pour augmenter la version db (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 une table conserve la trace de votre version db actuelle.

Pour migrer vers le haut , vous exécutez une commande appelée "db: migrate" qui regarde votre version et applique les scripts nécessaires. Vous pouvez migrer 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 changez la base de données, vous enregistrez un nouveau script, et tout développeur peut l'appliquer pour amener sa base de données locale à la dernière version.

0
ajouté
C'est le choix pour les projets Ruby. L'équivalent le plus proche de cette conception dans java est migrations de schémas mybatis. Pour .NET, l'équivalent est code.google.com/p/migratordotnet . Ils sont tous d'excellents outils pour ce travail IMO.
ajouté l'auteur Dan Tanner, source

Redgate a un produit appelé Contrôle de source SQL . Il s'intègre avec TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce et Git.

0
ajouté

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

0
ajouté

La plupart des moteurs de bases de données devraient 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, donc vous pouvez le soumettre à Subversion, ou tout ce que vous utilisez. Il serait facile d'exécuter un diff sur les fichiers aussi.

0
ajouté
Oui, mais la différence des fichiers SQL ne vous donnera pas les scripts nécessaires pour mettre à jour votre db dev / prod d'une révision à l'autre
ajouté l'auteur Asaf Mesika, source

Il y a 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, il suffit de suivre les fichiers source.

0
ajouté

Jetez un coup d'œil au paquet 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 familier 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 le contrôle de la source. Bonne chance!

Je ne sais pas s'il y a quelque chose de si simple pour MSSQL.

0
ajouté

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

They have both an SQL server & Oracle version.

0
ajouté

PLSQL Developer, un outil de All Arround Automations, a un plugin pour les dépôts qui fonctionne bien (mais pas génial) avec Visual Source Safe.

From the web:

The Version Control Plug-In provides a tight integration between the PL/SQL Developer IDE >>and any Version Control System that supports the Microsoft SCC Interface Specification. >>This includes most popular Version Control Systems such as Microsoft Visual SourceSafe, >>Merant PVCS and MKS Source Integrity.

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

0
ajouté

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

 
   

Vous n'avez donc pas besoin de gérer cela de votre propre chef

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

0
ajouté
Pour Java, je recommande vivement de jeter un coup d'œil sur flywaydb.org ces jours-ci - voir aussi la comparaison des fonctionnalités sur ce site
ajouté l'auteur Karussell, source
nous utilisons la liquibase, mais nous utilisons 3 approches différentes pour les différentes informations: 1. structure (table, vues, ...): historique des changements 2. codes (procédures, pl / sql, fonctions): changelog avec un seul changeset marqué avec runalways = true runonchange = true 3. tables de codes, autres méta "constantes" stockées dans des tables: la même approche que pour les codes, un seul changeset, supprimer from, insérer toutes les infos
ajouté l'auteur Palesz, source

Ayez vos instructions create table initiales dans le contrôleur de version, puis ajoutez des instructions alter table, mais jamais modifier les fichiers, juste plus altérer les fichiers idéalement nommés séquentiellement, ou même comme "change set", ainsi vous pouvez trouver toutes les modifications pour un déploiement particulier.

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

0
ajouté

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. S'il vous plaît visitez l'URL ci-dessous pour le lien de téléchargement, où vous pourrez utiliser le logiciel pour un essai pleinement fonctionnel.

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

0
ajouté

Je suis un peu old school, en ce sens que j'utilise des fichiers source pour créer la base de données. Il y a 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 commence par mettre à jour le schéma principal dans project-database.sql, puis copiez les informations pertinentes dans le projet-updates.sql, par exemple les instructions ALTER TABLE. Je peux ensuite appliquer les mises à jour à la base de données de développement, le tester, l'itérer jusqu'à ce qu'il soit bien fait. Ensuite, archivez les fichiers, testez à nouveau et appliquez à la production.

En outre, j'ai généralement une table dans le DB - Config - tels 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 de mise à jour:

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

Le db_version ne change que lorsque la base de données est recréée, et le db_revision me donne une indication de la distance qui sépare la base de données de la base de données.

I could keep the updates in their own separate files, but I chose to mash them all together and use cut&paste to extract relevant sections. A bit more housekeeping is in order, i.e., remove ':' from $Revision 1.1 $ to freeze them.

0
ajouté

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

Quelqu'un a mentionné Rails Migrations. 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 que nous étions en train de déplacer vers Rails. Vous vérifiez les scripts de migration eux-mêmes dans le VCS. Voici un article de Pragmatic Dave Thomas sur le sujet.

0
ajouté

ER Studio allows you to reverse your database schema into the tool and you can then compare it to live databases.

Exemple: Inversez votre schéma de développement dans ER Studio - comparez-le à la production et il énumérera toutes les différences. Il peut écrire les changements ou simplement les pousser automatiquement.

Une fois que vous avez un schéma dans ER Studio, vous pouvez enregistrer le script de création ou l'enregistrer en tant que fichier binaire propriétaire et l'enregistrer dans le contrôle de version. Si vous voulez revenir à une version antérieure du schéma, il suffit de le vérifier et de le pousser sur votre plate-forme db.

0
ajouté

J'écris mes scripts de version db en parallèle avec le codage, et je garde les scripts de version dans une section spécifique au projet dans SS. Si je modifie le code qui nécessite un changement de base de données, je mets à jour le script de version en même temps. Avant de sortir, je lance le script de release sur un db propre (copié de la production) et je fais mes derniers tests dessus.

0
ajouté

En l'absence de VCS pour les changements de table, je les ai enregistrés sur 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.

0
ajouté

Si vous utilisez SQL Server, il sera difficile de battre Data Dude (aka Database Edition de Visual Studio). Une fois que vous avez compris, faites une comparaison de schéma entre votre version contrôlée 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 DDL diff.

Il existe une vidéo sur MSDN qui est très utile.

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

0
ajouté

Nous avons utilisé Édition de la base de données MS Team System avec une très bonne qualité Succès. Il s'intègre plus ou moins avec le contrôle de version TFS et Visual Studio et nous permet de gérer facilement les procs 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 le contrôle qualité et la production sont extrêmement simples.

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

0
ajouté

MyBatis (formerly iBatis) has a schema migration, tool for use on the command line. It is written in java though can be used with any project.

Pour obtenir de bonnes pratiques de gestion du changement de base de données, nous devons identifier quelques objectifs clés.   Ainsi, le MyBatis Schema Migration System (ou MyBatis Migrations pour faire court) cherche à:

  • Travailler avec n'importe quelle base de données, nouvelle ou existante
  • Tirer parti du système de contrôle de la source (par exemple Subversion)
  • Permettre aux développeurs ou équipes concurrents de travailler de manière indépendante
  • Autoriser les conflits très visibles et facilement gérables
  • Autoriser la migration vers l'avant et vers l'arrière (évoluer, dévier 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 de bonnes pratiques cohérentes
0
ajouté