Mécanismes pour le suivi de la DB modifications de schéma
Quelles sont les meilleures méthodes pour le suivi et/ou l'automatisation DB modifications de schéma? 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 (en poussant développe à un serveur de test, déploiement de code testé sur un serveur de production), mais nous sommes encore en train de faire de la base de données mises à jour manuellement. Je voudrais trouver ou de créer une solution qui nous permet de travailler efficacement sur des serveurs avec des environnements différents, tout en continuant à utiliser Subversion comme une interface à travers laquelle le code de base de données et mises à jour autour de différents serveurs.
De nombreux logiciels populaires forfaits comprennent l'auto-mise à jour des scripts qui détecte la version DB et appliquer les changements nécessaires. Est-ce la meilleure façon de le faire, même sur une plus grande échelle (à travers de multiples projets et parfois de multiples environnements et les langues)? Si oui, est-il un code qui simplifie le processus ou est-il préférable de simplement rouler notre propre solution? Quelqu'un a mis en place quelque chose de semblable auparavant et intégré dans la Subversion post-commit des crochets, ou est-ce une mauvaise idée?
Tout une solution qui prend en charge de multiples plates-formes serait préférable, nous avons absolument besoin de l'appui de la Linux/Apache/MySQL/PHP pile comme la majorité de notre travail est sur cette plate-forme.
Vous devez vous connecter pour publier un commentaire.
Dans les Rails, il y a la notion de migrations, les scripts dans lequel les modifications apportées à la base de données sont prises en Ruby, plutôt que d'une base de données spécifique à la saveur de SQL. Votre Ruby code des migrations finit par être convertie en DDL spécifiques à votre base de données actuelle; ce qui rend la commutation de la base de données des plates-formes très facile.
Pour chaque modification que vous apportez à la base de données, vous écrivez une nouvelle migration. Les Migrations ont généralement deux méthodes: un "up" de la méthode dans laquelle les modifications sont appliquées et un "bas" de la méthode dans laquelle les modifications sont annulées. Une seule commande affiche 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 les Rails, les migrations sont conservés dans leur propre répertoire dans le répertoire du projet et obtenir vérifié dans le contrôle de version comme tout autre projet de code.
Cet Oracle guide Rails migrations couvre les migrations assez bien.
Les développeurs qui utilisent d'autres langues ont regardé les migrations et les ont mis en œuvre leurs propres versions linguistiques spécifiques. Je sais de Ruckusing, PHP migrations de système qui s'inspire de Rails pour les migrations; il pourrait être ce que vous cherchez.
Nous utilisons quelque chose de semblable à bcwoord pour garder nos schémas de base de données synchronisées à travers 5 différents types d'installations (production, mise en scène et un peu de développement des installations), et sauvegardés dans le contrôle de version, et ça marche plutôt bien. Je vais développer un peu:
Pour synchroniser la structure des bases de données, nous avons un seul script, update.php et un certain nombre de fichiers numérotés de 1.sql, 2.sql, 3.sql, etc. Le script utilise une table supplémentaire pour stocker le numéro de la version actuelle de la base de données. Le N. sql fichiers sont fabriqués à la main, pour aller à partir de la version (N-1) pour la version N de la base de données.
Ils peuvent être utilisés pour ajouter des tables, ajouter des colonnes, migrer des données à partir d'un ancien à un nouveau format de colonne puis déposez la colonne, insérer "maître" lignes de données tels que les types d'utilisateur, etc. Fondamentalement, il peut tout faire, et avec une bonne migration de données de scripts que vous ne serez jamais perdre de données.
Le script de mise à jour fonctionne comme ceci:
Tout se passe dans le contrôle de source, et chaque installation a un script pour mettre à jour vers la dernière version avec une seule exécution de script (appel update.php avec la bonne base de données de mot de passe etc.). Nous SVN update mise en scène et les environnements de production via un script qui appelle automatiquement la base de données le script de mise à jour, de sorte qu'un code de mise à jour est livré avec le nécessaire de base de données mises à jour.
On peut aussi utiliser le même script pour recréer la base de données entière à partir de zéro, nous venons de supprimer et recréer la base de données, puis exécutez le script qui va complètement à repeupler la base de données. On peut aussi utiliser le script pour remplir une base de données vide pour le test automatisé.
Il n'a fallu que quelques heures pour mettre en place ce système, c'est un concept simple et tout le monde obtient le schéma de numérotation des versions, et il a été d'une valeur inestimable dans le fait d'avoir la capacité d'aller de l'avant et de l'évolution de la conception de base de données, sans avoir à communiquer ou exécutez manuellement les modifications sur toutes les bases de données.
Attention lors du collage des requêtes à partir de phpMyAdmin si! Ces requêtes générées comprennent généralement le nom de base de données, ce qui vous ne voulez certainement pas, car il va briser 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 pré-commentaire SVN crochet qui va interdire .les fichiers sql contenant lesmydbchaîne, ce qui est un signe certain que quelqu'un copie/collé à partir de phpMyAdmin sans vérification appropriée.Mon équipe scripts de toutes les modifications de base de données, et s'engage à ceux des scripts pour SVN, avec chaque nouvelle version de l'application. Cela permet des changements progressifs de la base de données, sans perdre toutes les données.
Pour passer d'une version à la suivante, vous avez juste besoin d'exécuter l'ensemble des scripts de modification, et de votre base de données est à jour, et vous avez encore toutes vos données. Il peut ne pas être la méthode la plus simple, mais il est certainement efficace.
La question ici est de rendre vraiment facile pour les développeurs d'écrire ses propres modifications locales dans le contrôle de source de partager avec l'équipe. J'ai été confronté à ce problème depuis de nombreuses années, et a été inspiré par la fonctionnalité de Visual Studio pour la Base de données des professionnels. Si vous voulez un outil open-source avec les mêmes caractéristiques, essayez ceci: http://dbsourcetools.codeplex.com/
Amusez-vous,
- Nathan.
Si vous êtes toujours à la recherche de solutions : nous proposons un outil appelé neXtep designer. C'est un environnement de développement de base de données avec laquelle vous pouvez mettre l'ensemble de votre base de données sous contrôle de version. Vous travaillez sur une version dépôt contrôlé où chaque changement peuvent être suivis.
Lorsque vous avez besoin de libérer une mise à jour, vous pouvez valider vos composants et le produit sera automatiquement générer le SQL script de mise à niveau de la version précédente. Bien sûr, vous pouvez générer ce SQL à partir d'une des 2 versions.
Ensuite, vous avez plusieurs options : vous pouvez prendre ces scripts et de les mettre dans votre SVN avec votre code d'application, de sorte qu'il sera déployé par votre mécanisme existant. Une autre option est d'utiliser le mécanisme de livraison de neXtep : les scripts sont exportés dans quelque chose appelé un "colis" (scripts SQL + descripteurs XML), et d'un programme d'installation peut comprendre ce paquet et de le déployer sur un serveur cible, tout en assurant strcutural cohérence, de la vérification des dépendances, de l'enregistrement de la version installée, etc.
Le produit est GPL et est basé sur Eclipse pour qu'il fonctionne sur Linux, Mac et windows. Il a également le soutien d'Oracle, Mysql et Postgresql pour le moment (DB2 support est sur le chemin). Avoir un oeil sur le wiki où vous trouverez de plus amples informations :
http://www.nextep-softwares.com/wiki
Dump de votre schéma dans un fichier et l'ajouter à la source de contrôle. Alors qu'un simple diff va vous montrer ce qui a changé.
Scott Ambler produit une grande série d'articles (et co-auteur d'un livre) sur la base de données de refactoring, avec l'idée qu'il faut essentiellement s'appliquer TDD les principes et les pratiques de l'entretien de votre schéma. Vous avez mis en place une série de structure et de graines de données de tests unitaires pour la base de données. Puis, avant de changer quoi que ce soit, de modifier/é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 de base nom de la colonne et le type de données vérifie dans une suite de tests unitaires. Nous pouvez relancer les essais à tout moment pour vérifier que la base de données dans la version SVN correspond à la vivre db l'application est en cours d'exécution.
Comme il s'avère, les développeurs aussi parfois modifier leurs sandbox de base de données et de la négligence, de mettre à jour le fichier de schéma dans le SVN. Le code repose alors sur une db changement qui n'a pas été vérifié. Ce genre de bug peut être maddeningly difficile à cerner, mais la suite viendra la chercher tout de suite. Ceci est particulièrement bien si vous l'avez construit dans une plus grande Intégration Continue plan.
K. Scott Allen a un bon article ou deux sur la version de schéma, qui utilise la mise à jour incrémentielle scripts/migrations concept référencé dans d'autres réponses ici; voir http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.
Elle est un peu faible technologie, et il pourrait y avoir une meilleure solution, mais vous pourriez tout simplement mettre 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 connais pas la commande malheureusement.
Ensuite, engager le script dans le contrôle de code source avec le code qui fonctionne sur elle. Lorsque vous avez besoin de modifier le schéma avec le code, le script peut être vérifié dans le long avec le code que nécessite le changement de schéma. Ensuite, diff sur le script indique diff sur les modifications de schéma.
Avec ce script, vous pouvez l'intégrer à DBUnit ou une sorte de script de construction, de sorte qu'il semble qu'elle pourrait s'insérer dans votre processus automatisés.
Si vous êtes à l'aide de C#, jetez un oeil à Subsonique, un très utile outil ORM, mais aussi génère le script sql de recréé votre régime et /ou de données. Ces scripts peuvent être mis dans le contrôle de source.
http://subsonicproject.com/
J'ai utilisé la base de données suivante de la structure de projet dans Visual Studio pour plusieurs projets et c'est assez bien travaillé:
Base de données
Notre système de construction, puis les mises à jour de la base de données à partir d'une version à l'autre en exécutant les scripts dans l'ordre suivant:
Chaque développeur vérifie leurs modifications pour un bug/feature en ajoutant leur code à la fin de chaque fichier. Une fois l'un des principaux version est complète et ramifiée dans le contrôle de source, le contenu de l' .les fichiers sql dans les Scripts de Modification de dossier sont supprimés.
Nous utilisons un très simple, mais encore de solution efficace.
Pour les nouvelles installations, nous avons un métadonnées.fichier sql dans le répertoire qui contient tous les DB de schéma, puis dans le processus de construction nous utiliser ce fichier pour générer la base de données.
Pour les mises à jour, nous avons ajout des mises à jour dans le logiciel codé en dur. Nous le gardons codé en dur car nous n'aimons pas résoudre les problèmes avant c'EST vraiment un problème, et ce genre de chose n'a pas posé de problème jusqu'à présent.
Donc, dans notre logiciel, nous avons quelque chose comme ceci:
RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');Ce code permet de vérifier si la base de données dans la version 1 (qui est stocké dans un tableau créé automatiquement), si elle est dépassée, la commande est alors exécutée.
Mettre à jour les métadonnées.sql dans le référentiel, nous lançons cette mises à niveau local, puis l'extrait de la base de données complète des métadonnées.
La seule chose qui arrive souvent, c'est oublier de publier les métadonnées.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 pourrait arriver, c'est de faire une nouvelle installation avec une ancienne base de données et la mise à niveau lors de la première utilisation.
Aussi nous ne supportons pas de décote, mais c'est de par leur conception, si quelque chose se brise sur une mise à jour, nous avons restauré la version précédente et d'en fixer la mise à jour avant d'essayer de nouveau.
Je créer les dossiers nommés après la construction, les versions et les mises à niveau et le déclassement des scripts de là. Par exemple, vous pourriez avoir les dossiers suivants: 1.0.0, 1.0.1 et 1.0.2. Chacun d'eux contient le script qui permet d'augmenter ou de réduire votre base de données entre les versions.
Si un client ou un client que vous appelez avec un problème avec la version 1.0.1 et que vous utilisez la version 1.0.2, apportant de la base de données de revenir à sa version ne sera pas un problème.
Dans votre base de données, créer une table appelée "schéma" où vous avez mis dans la version actuelle de la base de données. Puis écrivez un programme qui peut augmenter ou de réduire votre base de données pour vous, c'est facile.
Tout comme Joey dit, si vous êtes dans un des Rails de monde, utiliser les Migrations. 🙂
Pour mon projet PHP, nous utilisons l'idée de rails migrations et nous avons un des migrations répertoire dans lequel nous conserver les fichiers titre "migration_XX.sql" où XX est le numéro de la migration. Actuellement, ces fichiers sont créés par la main comme des mises à jour sont faites, mais leur création pourrait être facilement modifié.
Ensuite, nous avons un script qui s'appelle "Migration_watcher" qui, comme nous sommes en pré-alpha, qui se déroule actuellement à chaque chargement de page et vérifie si il y a un nouveau migration_XX.fichier sql où XX est plus grand que la migration de la version. Si donc il exécute tous migration_XX.les fichiers sql jusqu'à le plus grand nombre contre la base de données et le tour est joué! les modifications de schéma sont automatisées.
Si vous avez besoin de la possibilité de rétablir le système exigerait beaucoup de peaufinage, mais elle est simple et a travaillé très bien pour notre taille relativement petite de l'équipe jusqu'à présent.
Je recommande l'utilisation de Ant (cross platform) pour le "script" de côté (car il peut pratiquement parler à n'importe db sortir de là, via jdbc) et la Subversion de la source de dépôt.
Fourmi va vous permettre de sauvegarder votre base de données vers des fichiers locaux, avant de faire des changements.
1. sauvegarde de la base de données existante schéma de fichier via Ant
2. le contrôle de version de dépôt Subversion via Ant
3. envoyer de nouvelles instructions sql à la base de données via Ant
Toad for MySQL dispose d'une fonction appelée la comparaison de schémas qui vous permet de synchroniser 2 bases de données. C'est le meilleur outil que j'ai utilisé jusqu'à présent.
J'aime la façon dont Yii poignées de migrations de base de données. Une migration est en fait un script PHP de mise en œuvre
CDbMigration.CDbMigrationdéfinit unupméthode qui contient la migration de la logique. Il est également possible de mettre en œuvre undownméthode pour soutenir la reprise de la migration. Sinon,safeUpousafeDownpeut être utilisé pour s'assurer que la migration est effectuée dans le cadre d'une transaction.Yii l'outil de ligne de commande
yiiccontient la prise en charge de créer et d'exécuter des migrations. Les Migrations peuvent être appliquées ou inversé, soit un par un ou par lot. La création d'un des résultats de la migration dans le code PHP de la classe de mise en œuvre deCDbMigration, au nom unique, basé sur un horodatage et une migration nom spécifié par l'utilisateur. Toutes les migrations qui ont déjà été appliquées à la base de données sont stockées dans un tableau de migration.Pour plus d'informations, voir la Migration De Base De Données article dans le manuel.
Essayer db-déployer - principalement un outil Java, mais fonctionne avec php.
À mon humble avis, les migrations ont un énorme problème:
Mise à niveau d'une version à l'autre fonctionne très bien, mais en faire une nouvelle installation d'une version donnée pourrait prendre une éternité si vous avez des centaines de tableaux et une longue histoire de l'évolution (comme nous le faisons).
De l'exécution de l'ensemble de l'histoire de deltas depuis la base jusqu'à la version actuelle (pour des centaines de clients de bases de données) peut prendre un temps très long.
Il y a une ligne de commande mysql-diff outil qui compare les schémas de base de données, où schéma peut être direct ou de base de données SQL script sur le disque. Il est bon pour la plupart schéma tâches de migration.