Comment faites-vous la version de votre schéma de base de données? [fermé]

128

Comment préparez-vous vos deltas SQL? enregistrez-vous manuellement chaque SQL de changement de schéma dans un dossier delta, ou avez-vous une sorte de processus de différence automatisé?

Je suis intéressé par les conventions pour le schéma de base de données de versioning avec le code source. Peut-être un hook pré-commit qui diffère le schéma?

En outre, quelles options pour les deltas différents existent en dehors de DbDeploy ?

EDIT: en voyant les réponses, je voudrais préciser que je suis familier avec le schéma standard pour exécuter une migration de base de données à l'aide de deltas. Ma question concerne la création des deltas eux-mêmes, de préférence automatiquement.

De plus, la gestion des versions est pour PHP et MySQL si cela fait une différence. (Pas de solutions Ruby s'il vous plaît).

sql mysql schema versioning Eran Galperin
la source
J'utilise schemasync pour générer un correctif (et un script de restauration). Ceux-ci sont ajoutés au repo SVN. Ce n'est pas parfait mais cela fonctionne bien pour moi. De plus, déployer des changements de schéma est assez facile avec schemasync
Jay Sidri
Ce lien semble vide - existe-t-il toujours?
jocull le
On dirait que c'est déplacé: github.com/mmatuson/SchemaSync
Jay Sidri

Réponses:

61

Voir

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

Comment faire une version de ma base de données MS SQL dans SVN?

et l'article de Jeff

Obtenez votre base de données sous contrôle de version

Je ressens votre douleur et j'aimerais qu'il y ait une meilleure réponse. Cela pourrait être plus proche de ce que vous recherchiez.

Mécanismes de suivi des modifications de schéma de base de données

En général, j'estime qu'il n'y a pas de solution adéquate et acceptée à ce problème, et je lance la mienne dans ce domaine.

harpo
la source
Comme vous pouvez le voir d'après ma question, je connais le concept de deltas. Ma question porte sur les conventions pour les créer, de préférence automatiquement.
Eran Galperin
Je suppose que je vais rouler moi-même alors ...;)
Eran Galperin
Avez-vous essayé DBDiff: github.com/DBDiff/DBDiff ? C'est un bon choix pour ce que vous recherchez @EranGalperin car il effectue des migrations automatisées pour le schéma et les données en SQL. Divulgation Je suis le développeur derrière!
Jasdeep Khalsa
4

Si vous êtes toujours à la recherche d'options: jetez un œil à neXtep designer. Il s'agit d'un environnement de développement de base de données GPL gratuit basé sur les concepts de contrôle de version. Dans l'environnement, vous travaillez toujours avec des entités versionnées et vous pouvez vous concentrer sur le développement du modèle de données. Une fois qu'une version est terminée, le moteur de génération SQL branché sur le système de contrôle de version peut générer n'importe quel delta dont vous avez besoin entre 2 versions, et vous offrira un mécanisme de livraison si vous en avez besoin.

Entre autres, vous pouvez synchroniser et inverser la synchronisation de votre base de données lors des développements, créer des diagrammes de modèles de données, interroger votre base de données à l'aide de clients SQL intégrés, etc.

Jetez un œil au wiki pour plus d'informations: http://www.nextep-softwares.com/wiki

Il prend actuellement en charge Oracle, MySql et PostgreSql et est en java afin que le produit fonctionne sous Windows, Linux et Mac.

Christophe Fondacci
la source
3

Je m'assure que les changements de schéma sont toujours additifs. Je ne laisse donc pas tomber les colonnes et les tables, car cela zapperait les données et ne pourra pas être restauré plus tard. De cette façon, le code qui utilise la base de données peut être restauré sans perdre de données ou de fonctionnalités.

J'ai un script de migration qui contient des instructions qui créent des tables et des colonnes si elles n'existent pas encore et les remplit de données.

Le script de migration s'exécute chaque fois que le code de production est mis à jour et après de nouvelles installations.

Lorsque je souhaite supprimer quelque chose, je le fais en les supprimant du script d'installation de la base de données et du script de migration afin que ces éléments de schéma obsolètes soient progressivement supprimés dans les nouvelles installations. Avec l'inconvénient que les nouvelles installations ne peuvent pas revenir à une version plus ancienne avant l'installation.

Et bien sûr, j'exécute des DDL via ces scripts et jamais directement sur la base de données pour garder les choses synchronisées.

Calmaire
la source
2

Je ne gère pas les deltas. J'apporte des modifications à une base de données principale et dispose d'un outil qui crée un script de construction basé sur XML basé sur la base de données principale.

Quand vient le temps de mettre à niveau une base de données existante, j'ai un programme qui utilise le script de construction basé sur XML pour créer une nouvelle base de données et les tables nues. Je copie ensuite les données de l'ancienne base de données en utilisant INSERT INTO x SELECT FROM y, puis j'applique tous les index, contraintes et déclencheurs.

Les nouvelles tables, les nouvelles colonnes, les colonnes supprimées sont toutes gérées automatiquement et avec quelques petites astuces pour ajuster la routine de copie, je peux gérer les changements de nom de colonne, les changements de type de colonne et d'autres refactorisations de base.

Je ne recommanderais pas cette solution sur une base de données avec une énorme quantité de données mais je mets régulièrement à jour une base de données de plus de 1 Go avec 400 tables.

Darrel Miller
la source
Cela semble quelque peu fastidieux, en particulier lorsqu'il s'agit de plusieurs développeurs. De plus, le processus de construction semble exigeant, et j'aimerais être aussi simple que possible.
Eran Galperin
J'admets qu'il a fallu un certain temps pour réussir, mais maintenant, il ne nécessite presque aucun effort pour préparer une mise à niveau et encore moins pour en effectuer une. En outre, une chose que j'aime, c'est que je peux faire des changements de correctifs provisoires et cela n'a aucun impact sur la procédure de mise à niveau. Chaque mise à niveau est une nouvelle base de données.
Darrel Miller
2

Vous n'avez pas mentionné le SGBDR que vous utilisez, mais s'il s'agit de MS SQL Server, la comparaison SQL de Red-Gate nous a été indispensable pour créer des deltas entre les scripts de création d'objets.

Jalbert
la source
1
C'est pour Mysql, j'ai mis à jour ma question
Eran Galperin
2

Je ne suis pas du genre à faire mon propre cornet, mais j'ai développé une application Web interne pour suivre les modifications apportées aux schémas de base de données et créer des scripts de mise à jour versionnés.

Cet outil s'appelle Brazil et est désormais open source sous licence MIT. Le Brésil est basé sur ruby ​​/ ruby ​​on rails et prend en charge le déploiement des modifications dans toutes les bases de données prises en charge par Ruby DBI (MySQL, ODBC, Oracle, Postgres, SQLite).

Un support pour mettre les scripts de mise à jour en contrôle de version est prévu.

Joakim Bodin
la source
Le Brésil a l'air plutôt bien, dommage que j'utilise principalement PHP. Avez-vous déjà envisagé de porter le système?
Eran Galperin
1

Nous exportons les données vers un format portable (en utilisant notre chaîne d'outils), puis nous les importons dans un nouveau schéma. pas besoin de delta SQL. Hautement recommandé.

Shachar
la source
3
Quel est ce format portable? et comment l'importer dans le nouveau schéma en appliquant uniquement les différences par rapport à la version précédente?
Eran Galperin
1

J'utilise la base de données Firebird pour la plupart des développements et j'utilise l' outil d'administration FlameRobin pour cela. Il a une belle option pour enregistrer toutes les modifications. Il peut tout consigner dans un seul gros fichier ou un fichier par modification de base de données. J'utilise cette deuxième option, puis je stocke chaque script dans un logiciel de contrôle de version - auparavant j'utilisais Subversion, maintenant j'utilise Git.

Je suppose que vous pouvez trouver un outil MySQL qui a la même fonctionnalité de journalisation que FlameRobin pour Firebird.

Dans l'une des tables de base de données, je stocke le numéro de version de la structure de la base de données, afin de pouvoir mettre à niveau n'importe quelle base de données facilement. J'ai également écrit un simple script PHP qui exécute ces scripts SQL un par un sur n'importe quelle base de données cible (le chemin de la base de données et le nom d'utilisateur / mot de passe sont fournis sur la ligne de commande).

Il existe également une option pour consigner toutes les instructions DML (insertion, suppression de mise à jour), et j'active cela en modifiant certaines données «par défaut» que contient chaque base de données.

J'ai écrit un joli livre blanc sur la façon dont je fais tout cela en détail. Vous pouvez télécharger le document au format .pdf avec des scripts de démonstration PHP à partir d' ici .

Milan Babuškov
la source
1

J'ai également développé un ensemble de scripts PHP où les développeurs peuvent soumettre leurs scripts deltasql à un référentiel central.

Dans l'une des tables de la base de données (appelée TBSYNCHRONIZE), je stocke le numéro de version du dernier script exécuté, afin que je puisse mettre à niveau n'importe quelle base de données facilement en utilisant l'interface Web ou un client développé spécialement pour Eclipse.

L'interface web permet de gérer plusieurs projets. Il prend également en charge les "branches" de base de données.

Vous pouvez tester l'application sur http://www.gpu-grid.net/deltasql (si vous vous connectez en tant qu'administrateur avec le mot de passe testdbsync). L'application est open source et peut être téléchargée ici: http://sourceforge.net/projects/deltasql

deltasql est utilisé de manière productive en Suisse et en Inde, et est populaire au Japon.

Tiziano Mengotti
la source
1

Il y a quelques mois, j'ai cherché un outil pour le contrôle de version du schéma MySQL. J'ai trouvé de nombreux outils utiles, comme la migration de Doctrine, la migration RoR, certains outils écrits en Java et Python.

Mais aucun d'entre eux n'a satisfait mes exigences.

Mes exigences:

  1. Aucune exigence, exclure PHP et MySQL
  2. Aucun fichier de configuration de schéma, comme schema.yml dans Doctrine
  3. Capable de lire le schéma actuel à partir de la connexion et de créer un nouveau script de migration, puis de représenter un schéma identique dans d'autres installations d'application.

J'ai commencé à écrire mon outil de migration, et aujourd'hui j'ai la version beta.

S'il vous plaît, essayez-le, si vous êtes intéressé par ce sujet. Merci de m'envoyer vos futures demandes et rapports de bogues.

Code source: bitbucket.org/idler/mmp/src Vue d'ensemble en anglais: bitbucket.org/idler/mmp/wiki/Home Vue d'ensemble en russe: antonoff.info/development/mysql-migration-with-php-project

Maxim Antonov
la source
Vous disposez également d'un nouvel outil: DBV: stackoverflow.com/a/13837473/6309
VonC
1

Je suis également intéressé par ce sujet.

Il y a quelques discussions sur ce sujet dans le wiki Django .

Fait intéressant, il semble que CakePHP ait intégré la gestion des versions de schéma en utilisant simplement la cake schema generatecommande.

Swaroop CH
la source
D'après ce que j'ai lu sur la solution de cake - il s'agit d'un versionnage dans un sens très basique, mais il n'a pas de capacités différentes, donc cela ne me sert à rien.
Eran Galperin
1

Pour MySQL

Quand j'atterris sur une nouvelle DB:

Tout d'abord, je vérifie la structure:

mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql
mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql
diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt
cat DIFF_FILENAME.txt | less

Grâce aux utilisateurs de stackoverflow, j'ai pu écrire ce script rapide pour trouver les différences de structure.

src: https://stackoverflow.com/a/8718572/4457531 et https://stackoverflow.com/a/26328331/4457531

Dans un second temps, je vérifie les données, table par table avec mysqldiff. C'est un peu archaïque mais une boucle php basée sur des information_schemadonnées fait le travail sûrement

Pour la gestion des versions, j'utilise la même manière mais je formate un script de mise à jour SQL (pour mettre à niveau ou restaurer) avec des résultats de différence et j'utilise la convention de numéro de version (avec plusieurs modifications, le numéro de version ressemble à une adresse IP) .

initial version : 1.0.0
                  ^ ^ ^
                  | | |
structure change: - | |
datas added: -------- |
datas updated: --------
Nolwennig
la source
0

J'utilise un contrôle de version strict du schéma de base de données (suivi dans une table séparée). Les scripts sont stockés dans le contrôle de version, mais ils vérifient tous la version actuelle du schéma avant d'apporter des modifications.

Voici l'implémentation complète de SQL Server (la même solution pourrait être développée pour MySQL si nécessaire): Comment gérer la version du schéma de base de données SQL Server

Zoran Horvat
la source
Je viens de lire votre article. L'utilisez-vous toujours ou avez-vous depuis adopté une solution standard telle que DBUp ou ReadyRoll?
David Atkinson le
Actuellement, tous mes projets reposent sur Entity Framework Code-First et j'utilise ses migrations pour versionner la base de données. J'ai la solution de l'article dans quelques projets hérités et je ne l'ai jamais remplacée. Dans d'autres projets, j'ai utilisé les outils Redgate pour gérer le schéma et les migrations.
Zoran Horvat le
Super que vous soyez un utilisateur de Redgate! Si vous souhaitez utiliser les outils Redgate en conjonction avec EF, c'est possible: red-gate.com/blog/database-lifecycle-management/…
David Atkinson
Je vais m'assurer de l'essayer à la prochaine occasion. Cela nous a bien servi, mais j'ai changé l'équipe entre-temps et maintenant j'expérimente le support EF natif avant de le faire avancer.
Zoran Horvat le
0

Après une longue enquête, j'ai découvert qu'il existe des outils tiers ou des types de projets Visual Studio qui ne me satisfont pas, ou juste des blogs sur la théorie mais pas d'implémentation. J'ai donc mis en place un système de travail, qui est utilisé presque un an, et expliqué ici:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

en fonction de l'intérêt, continuera à écrire plus.

Yuksel Daskin
la source
2
Bonjour, bienvenue à SO. Cette réponse n'est pas vraiment complète, elle ne fournit en gros qu'un lien. Les réponses aux liens uniquement ne sont pas les meilleures: si le lien devait devenir invalide, votre réponse deviendrait inutile. Veuillez donc le modifier et ajouter au moins un résumé de ce qui peut y être trouvé, afin que votre réponse ait une valeur indépendamment du lien. Je vous remercie!
Fabio dit réintégrer Monica le