• # Il n'y pas de remède miracle

    Posté par (site web personnel) . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 3. Dernière modification le 15 septembre 2013 à 15:31.

    Je viens vers vous pour savoir comment vous géreriez ce cas là.

    C'est une problématique très large, la réponse peut tenir en trois lignes... ou bien occuper une service de devs pendant plusieurs mois!

    En inglishe, cela s'appelle un «database scheme upgrade» et une «data migration» — juste pour t'aiguiller dans tes recherches.

    Pour définir ta stratégie, tu dois définir tes objectifs et faire la liste de tes contraintes. Voici quelques questions pour commencer.

    Pour définir tes objectifs:

    • Après la mise à jour de sa BD consécutive à la MÀJ de 1 à 2 de ton soft, l'utilisateur remarque que sa fonction préférée qui marchait très bien dans 1 ne marche pas dans 2. Il ne peut se permettre d'attendre une MÀJ et souhaite retourner à la version 1. Comment fait-il?

    • Les système en prod peuvent-ils avoir un downtime?

    Tes contraintes:

    • Quels sont les systèmes de BD supportés?

    • L'upgrade de BD se fait côté soft ou bien avec un script SQL/sh?

    • Qui fait l'upgrade (admin, utilisateur inexpérimenté?)

    • Ton nouveau schéma est-il un sur ensemble strict de l'ancien (cas facile)?

    • Que doit-il se passer si la version 1 de ton soft tourne sur une BD avec le schéma de la version 2?