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

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).

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.

Vous pourriez jeter un œil à un autre fil de discussion similaire: Comment puis-je versionner ma base de données MS SQL dans SVN? .

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.

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.

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.

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.

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.

http://bitbucket.org/idler/mmp - outil de gestion des versions de schéma pour mysql, écrit en PHP

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é.

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 .

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.

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

J'utilise http://code.google.com/p/oracle-ddl2svn/

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.

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: --------

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

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.