Les mécanismes de changement de schéma DB de suivi

voix
128

Quelles sont les meilleures méthodes pour le suivi et / ou l'automatisation des changements de schéma DB? Notre équipe utilise Subversion pour le contrôle de version et nous avons été en mesure d'automatiser certaines de nos tâches de cette façon (pousser construit jusqu'à un serveur intermédiaire, le déploiement code testé sur un serveur de production), mais nous faisons encore des mises à jour de base de données manuellement. Je voudrais trouver ou de créer une solution qui nous permet de travailler efficacement sur les serveurs avec des environnements différents, tout en continuant à utiliser Subversion comme back-end à travers lequel les mises à jour de code et DB sont bousculés à différents serveurs.

De nombreux logiciels populaires incluent des scripts mise à jour automatique qui détectent la version DB et appliquer les modifications nécessaires. Est-ce la meilleure façon de le faire même à plus grande échelle (sur plusieurs projets et parfois plusieurs environnements et langues)? Si oui, est-il un code existant là-bas qui simplifie le processus ou est-il préférable de rouler juste notre propre solution? Quelqu'un at-il mis en œuvre quelque chose de semblable avant et intégré dans Subversion post-commit crochets, ou est-ce une mauvaise idée?

Même si une solution qui prend en charge plusieurs plates-formes serait préférable, nous avons absolument besoin pour soutenir Linux / Apache / MySQL pile / PHP comme la majorité de notre travail est sur cette plate-forme.

Créé 04/08/2008 à 22:31
source utilisateur
Dans d'autres langues...                            


20 réponses

voix
54

Dans le monde Rails, il y a le concept des migrations, des scripts dans lesquels des modifications à la base de données sont faites dans Ruby plutôt que d'une saveur spécifique à la base de données SQL. Votre code de migration Ruby finit par être converti en particulier à votre base de données DDL actuelle; ce qui rend les plates-formes de commutation de base de données très facile.

Pour chaque modification apportée à la base de données, vous écrivez une nouvelle migration. Ont généralement deux migrations méthodes: une méthode « up » méthode où les modifications sont appliquées et un « bas » où les modifications sont annulées. Une commande unique apporte la base de données à jour, et peut également être utilisé pour mettre la base de données à une version spécifique du schéma. Dans Rails, les migrations sont conservés dans leur propre répertoire dans le répertoire du projet et se vérifier dans le contrôle de version comme tout autre code de projet.

Ce guide Oracle pour les migrations Rails couvre les migrations très bien.

Les développeurs utilisant d' autres langues se sont penchées sur les migrations et ont mis en œuvre leurs propres versions spécifiques à une langue. Je connais Ruckusing , une migration de PHP système qui est calqué sur les migrations Rails; il pourrait être ce que vous cherchez.

Créé 04/08/2008 à 23:45
source utilisateur

voix
48

Nous utilisons quelque chose de similaire à bcwoord pour maintenir notre base de données schèmes synchronisées sur 5 installations différentes (production, mise en scène et quelques installations de développement), et sauvegardés dans le contrôle de version, et il fonctionne très bien. Je vais élaborer un peu:


Pour synchroniser la structure de base de données, nous avons un seul script, update.php, et un certain nombre de fichiers numérotés 1.SQL, 2.sql, 3.sql, etc. Le script utilise une table supplémentaire pour stocker le numéro de version du base de données. Les fichiers N.sql sont fabriqués à la main, pour aller de la version (N-1) à la version N de la base de données.

Ils peuvent être utilisés pour ajouter des tables, ajouter des colonnes, la migration des données d'un ancien à un nouveau format de colonne puis déposez la colonne, insérer des lignes de données « maître », comme les types d'utilisateurs, etc. En fait, il peut faire quoi que ce soit, et avec les données correctes scripts de migration vous ne perdrez jamais de données.

Le script de mise à jour fonctionne comme ceci:

  • Connectez-vous à la base de données.
  • Faites une sauvegarde de la base de données en cours (parce que des choses se tromper) [mysqldump].
  • Créer table de comptabilité (appelée _meta) si elle n'existe pas.
  • Lire la version actuelle de la table _meta. Supposons que 0 si elle est introuvable.
  • Pour tous les fichiers .sql numérotés supérieure à la version, les exécuter pour
  • Si l'un des fichiers produit une erreur: revenir à la sauvegarde
  • Dans le cas contraire, mettez à jour la version dans la table de tenue de livres au fichier sql le plus exécuté.

Tout se passe dans le contrôle source, et chaque installation a un script de mise à jour à la dernière version avec une seule exécution de script (appel update.php avec le mot de passe base de données appropriée, etc.). Nous svn la mise en scène de mise à jour et les environnements de production via un script qui appelle automatiquement le script de mise à jour de base de données, une mise à jour de code est livré avec les mises à jour de base de données nécessaires.

On peut également utiliser le même script pour recréer la base de données à partir de zéro; nous venons et recréez la base de données, puis exécutez le script qui va complètement repeupler la base de données. Nous pouvons également utiliser le script pour remplir une base de données vide pour les tests automatisés.


Il n'a fallu que quelques heures pour mettre en place ce système, il est conceptuellement simple et tout le monde obtient le schéma de numérotation des versions, et il a été très précieux en ayant la capacité de se déplacer vers l'avant et faire évoluer la conception de base de données, sans avoir à communiquer ou exécuter manuellement les modifications sur toutes les bases de données.

Méfiez - vous lors du collage des requêtes de phpMyAdmin bien! Ces requêtes générées comprennent généralement le nom de base de données, que vous ne voulez certainement pas car il brisera vos scripts! Quelque chose comme CREATE TABLE mydb. newtable(...) échouera si la base de données sur le système n'est pas appelé mydb. Nous avons créé un crochet de SVN pré-commentaire qui désavouer .sql fichiers contenant la mydbchaîne, ce qui est un signe certain que quelqu'un copier / coller de phpMyAdmin sans vérification appropriée.

Créé 22/08/2008 à 15:44
source utilisateur

voix
11

Mes scripts de l'équipe sur tous les changements de base de données, et engage les scripts à SVN, ainsi que chaque version de l'application. Cela permet des changements progressifs de la base de données, sans perte de données.

Pour passer d'une version à l'autre, il vous suffit d'exécuter l'ensemble des scripts de modification et votre base de données est mise à jour, et vous avez encore toutes vos données. Il ne peut pas être la méthode la plus simple, mais il est certainement efficace.

Créé 05/08/2008 à 20:56
source utilisateur

voix
9

Si vous êtes toujours à la recherche de solutions: nous proposons un outil appelé concepteur Nextep. Il est un environnement de développement de base de données avec laquelle vous pouvez mettre votre base de données entière sous contrôle de version. Vous travaillez sur un référentiel contrôlé version où chaque changement peut être suivi.

Lorsque vous avez besoin de sortir une mise à jour, vous pouvez valider vos composants et le produit génère automatiquement le script de mise à niveau SQL de la version précédente. Bien sûr, vous pouvez générer ce SQL à partir des 2 versions.

Ensuite, vous avez beaucoup d'options: vous pouvez prendre ces scripts et les mettre dans votre SVN avec votre code d'application pour que ce sera déployée par votre mécanisme existant. Une autre option consiste à utiliser le mécanisme de distribution de Nextep: les scripts sont exportés dans ce qu'on appelle un « paquet de livraison » (scripts SQL + descripteur XML), et un programme d'installation peut comprendre ce paquet et le déployer sur un serveur cible tout en assurant la cohérence strcutural, la dépendance vérifier, enregistrer la version installée, etc.

Le produit est GPL et est basé sur Eclipse pour qu'il fonctionne sur Linux, Mac et Windows. Elle soutient également Oracle, Postgresql et Mysql au moment (prise en charge de DB2 est sur le chemin). Jetez un oeil sur le wiki où vous trouverez des informations plus détaillées: http://www.nextep-softwares.com/wiki

Créé 25/10/2010 à 06:46
source utilisateur

voix
9

La question ici est vraiment rend facile pour les développeurs de scripts leurs propres changements locaux dans le contrôle des sources de partager avec l'équipe. Je l' ai fait face à ce problème depuis de nombreuses années, et a été inspiré par la fonctionnalité de Visual Studio pour les professionnels de la base de données. Si vous voulez un outil open-source avec les mêmes caractéristiques, essayez ceci: http://dbsourcetools.codeplex.com/ Amusez -vous , - Nathan.

Créé 07/07/2009 à 14:26
source utilisateur

voix
6

Scott Ambler produit une grande série d'articles (et co-auteur d' un livre ) sur la base de données refactoring, avec l'idée que vous devriez essentiellement appliquer les principes TDD et pratiques pour l' entretien de votre schéma. Vous mettez en place une série de structure et des tests unitaires de données semences pour la base de données. Alors, avant de changer quoi que ce soit, vous modifiez / écrire des tests pour refléter ce changement.

Nous avons fait cela pendant un certain temps maintenant et il semble fonctionner. Nous avons écrit le code pour générer le nom de colonne de base et des contrôles dans datatype une suite de tests unitaires. Nous pouvons exécuter à nouveau les essais à tout moment pour vérifier que la base de données dans la caisse SVN correspond à la db en direct l'application est en fait en cours d'exécution.

Il se trouve que, les développeurs parfois bidouiller leur base de données de bac à sable et la négligence de mettre à jour le fichier de schéma dans SVN. Le code dépend alors d'un changement de db qui n'a pas été vérifié. Ce genre de bug peut être exaspérante difficile à cerner, mais la suite de tests ramasser tout de suite. Ceci est particulièrement agréable si vous l'avez intégré dans un plan d'intégration continue plus grande.

Créé 29/08/2008 à 05:51
source utilisateur

voix
6

Dump votre schéma dans un fichier et l'ajouter au contrôle de source. Alors simple diff vous montrera ce qui a changé.

Créé 06/08/2008 à 17:59
source utilisateur

voix
5

K. Scott Allen a un article décent ou deux sur le schéma versioning, qui utilise le concept des scripts de mise à jour incrémentielle / migrations référencées dans d' autres réponses ici; voir http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Créé 29/08/2008 à 06:11
source utilisateur

voix
5

Si vous utilisez C #, jetez un oeil à subsonique, un outil ORM très utile, mais est génère également un script SQL pour recréer votre système et \ ou des données. Ces scripts peuvent ensuite être mis dans le contrôle source.

http://subsonicproject.com/

Créé 04/08/2008 à 23:47
source utilisateur

voix
5

Il est un peu faible technologie, et il pourrait y avoir une meilleure solution là-bas, mais vous pouvez simplement stocker votre schéma dans un script SQL qui peut être exécuté pour créer la base de données. Je pense que vous pouvez exécuter une commande pour générer ce script, mais je ne sais pas la commande malheureusement.

Ensuite, engager le script dans le contrôle source ainsi que le code qui fonctionne sur elle. Lorsque vous avez besoin de changer le schéma ainsi que le code peut être vérifié le script en même temps que le code qui nécessite le schéma modifié. Ensuite, diffs sur le script indiquera diffs sur les changements de schéma.

Avec ce script, vous pouvez l'intégrer à DBUnit ou une sorte de script de compilation, il semble donc qu'il pourrait adapter à vos processus déjà automatisés.

Créé 04/08/2008 à 23:28
source utilisateur

voix
4

Je l'ai utilisé la structure du projet de base de données suivante dans Visual Studio pour plusieurs projets et il a travaillé très bien:

Base de données

Scripts de changement

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

création de scripts

sprocs

Les fonctions

vues

Notre système de construction met alors à jour la base de données d'une version à l'autre en exécutant les scripts dans l'ordre suivant:

1.PreDeploy.sql

2.SchemaChanges.sql

Contenu de Créer un dossier Scripts

2.DataChanges.sql

3.Permissions.sql

Chaque développeur vérifie dans leurs changements pour un bug particulier / fonctionnalité en y apposant leur code sur la fin de chaque fichier. Une fois une version majeure est complète et ramifiée dans le contrôle source, le contenu des fichiers .sql dans le changement dossier Scripts sont supprimés.

Créé 08/08/2008 à 19:31
source utilisateur

voix
4

Nous utilisons une solution très simple mais efficace.

Pour les nouvelles installations, nous avons un fichier metadata.sql dans le référentiel qui contient tout le schéma DB, puis dans le processus de construction que nous utilisons ce fichier pour générer la base de données.

Pour les mises à jour, nous ajoutons les mises à jour dans le logiciel hardcoded. Nous gardons hardcoded parce que nous ne voulons pas de problèmes à résoudre avant qu'il ne soit vraiment un problème, et ce genre de chose ne prouve pas un problème à ce jour.

Donc, dans notre logiciel, nous avons quelque chose comme ceci:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Ce code vérifie si la base de données est en version 1 (qui est stocké dans une table créée automatiquement), si elle est dépassée, la commande est exécutée.

Pour mettre à jour le metadata.sql dans le référentiel, nous courons ce mises à niveau local, puis extraire les métadonnées de base de données complète.

La seule chose qui arrive tout aussi souvent, est d'oublier le commiting metadata.sql, mais ce n'est pas un problème majeur, car il est facile de tester sur le processus de construction et aussi la seule chose qui puisse arriver est de faire une nouvelle installation avec une base de données obsolète et mis à jour sur la première utilisation.

En outre, nous ne soutenons pas révisions à la baisse, mais il est par la conception, si quelque chose se brise sur une mise à jour, nous avons restauré la version précédente et fixer la mise à jour avant d'essayer à nouveau.

Créé 08/08/2008 à 19:21
source utilisateur

voix
3

Je crée des dossiers nommés les versions de construction et mettre mise à niveau et downgrade scripts là-dedans. Par exemple, vous pouvez avoir les dossiers suivants: 1.0.0, 1.0.1 et 1.0.2. Chacun contient le script qui vous permet de rétrograder ou de mettre à jour votre base de données entre les versions.

Si un client ou d'un client que vous appelez un problème avec la version 1.0.1 et que vous utilisez 1.0.2, ce qui porte la base de données à sa version ne sera pas un problème.

Dans la base de données, créez une table appelée « schéma » où vous mettez dans la version actuelle de la base de données. Ensuite, écrire un programme qui peut augmenter ou diminuer votre base de données pour vous est facile.

Tout comme Joey dit, si vous êtes dans un monde Rails, utilisez les migrations. :)

Créé 05/08/2008 à 05:36
source utilisateur

voix
2

Essayez db-deploy - principalement un outil Java mais fonctionne avec php ainsi.

Créé 19/01/2012 à 02:52
source utilisateur

voix
2

J'aime la manière dont migrations de bases de données gère. Une migration est essentiellement un script PHP mise en œuvre CDbMigration. CDbMigrationdéfinit une upméthode qui contient la logique de migration. Il est également possible de mettre en œuvre une downméthode pour soutenir l' inversion de la migration. Alternativement, safeUpou safeDownpeut être utilisé pour assurer que la migration se fait dans le cadre d'une transaction.

L'outil de ligne de commande de yu yiiccontient le support pour créer et exécuter des migrations. Peuvent être appliqués les migrations ou inversées, soit un par un ou dans un lot. Création d' un résultat de migration dans le code pour une classe PHP mise en œuvre CDbMigration, un nom unique basé sur un horodatage et un nom de migration spécifiée par l'utilisateur. Toutes les migrations qui ont été précédemment appliquées à la base de données sont stockées dans une table de migration.

Pour plus d' informations , consultez la migration de base de données article du manuel.

Créé 25/06/2011 à 14:18
source utilisateur

voix
2

migrations IMHO ont un énorme problème:

Mise à niveau d'une version à l'autre fonctionne très bien, mais faire une nouvelle installation d'une version donnée pourrait prendre une éternité si vous avez des centaines de tables et une longue histoire de changements (comme nous).

Exécution de l'histoire de deltas depuis la mise en ligne de base à la version actuelle (pour des centaines de bases de données clients) peut prendre très longtemps.

Créé 12/03/2011 à 15:15
source utilisateur

voix
2

Toad for MySQL a une fonction appelée schéma comparer qui vous permet de synchroniser des bases de données 2. Il est le meilleur outil que je l'ai utilisé jusqu'à présent.

Créé 05/02/2011 à 12:08
source utilisateur

voix
2

Je recommanderais d'utiliser Ant (plate-forme de croix) pour le côté « script » (car il peut pratiquement parler à tout db là-bas par jdbc) et Subversion pour le dépôt source. Ant alow vous à « sauvegarder » votre base de données aux fichiers locaux, avant de faire des changements. 1. sauvegarde schéma db existant fichier via Ant 2. contrôle de version dans le référentiel Subversion via Ant 3. envoyer de nouvelles instructions SQL db via Ant

Créé 17/09/2008 à 17:54
source utilisateur

voix
2

Pour mon projet actuel de PHP nous utilisons l'idée de la migration des rails et nous avons un répertoire des migrations où nous gardons les fichiers titre « migration_XX.sql » où XX est le nombre de la migration. Actuellement, ces fichiers sont créés manuellement les mises à jour sont faites, mais leur création pourraient être facilement modifiés.

Ensuite, nous avons un script appelé « Migration_watcher » qui, comme nous sommes en pré-alpha, fonctionne actuellement sur chaque chargement de page et vérifie s'il y a un nouveau fichier migration_XX.sql où XX est plus grande que la version actuelle de la migration. Dans ce cas, il exécute tous les fichiers migration_XX.sql jusqu'à le plus grand nombre contre la base de données et le tour est joué! les modifications du schéma sont automatisés.

Si vous avez besoin la possibilité de rétablir le système, il faudrait beaucoup de peaufinage, mais il est simple et travaille très bien pour notre équipe assez petite jusqu'ici.

Créé 23/08/2008 à 13:58
source utilisateur

voix
0

Il y a une ligne de commande mysql-diff outil qui compare les schémas de base de données, où le schéma peut être une base de données en direct ou script SQL sur le disque. Il est bon pour la plupart des tâches de migration de schéma.

Créé 04/11/2009 à 20:43
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more