• # Solution pour une base MySQL.. que je m'étais inventé pour un projet pas open source

    Posté par . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 3.

    J'ai eu le même problème que toi sur un projet professionnel, je voulais maitriser les évolutions de mon schéma de base de donnée, et je m'étais organisé de manière assez similaire à toi mais en poussant un peu plus les version :

    • versioning dans SVN du shéma officiel en SQL avec TAG (crée avec MySQL Workbench) sous la forme d'un module
    • création d'une table appelée "version" avec pour premier champ la version correspondante... peut être qu'il serait plus logique à des fins de maintenance de pister la migration qui a coincé
    • A chaque nouvelle version du schéma je créais un fichier SQL d'upgrade du shéma de la version précédente vers la nouvelle version, en général je mettais à jour le fichier à chaque fois que je modifiais le schéma de référence.

    Par exemple, si dans mon cheminement de version j'avais une 1.1 puis une 1.2 et une 1.3

    Je me retrouvais avec les fichiers suivant :
    - upgrade1.1To1.2.sql
    - upgrade1.2To1.3.sql
    - shema.sql

    Lors de l'éxécution du setup d'upgrade, tout d'abord, je sauvegardais le schéma actuel, puis je détectais la installé, de manière à exécuter les scripts d'upgrade consécutif de manière à atteindre la bonne version de schéma.

    L'intéret de ces scripts, c'est qu'ils sont très facile à recetter de manière unitaire, il suffit de prendre le schéma de la version précédente (à vide) d'exécuter les scripts d'upgrade d'exporter la structure SQL générée et de la comparer avec le schéma officiel de la version.