Discussion :

[ElTchoupi]

[Résumé] Comment faire pour que le schéma DB (embarqué) de mon soft se mette à jours INTELLIGEMMENT avec l'évolution de ce dernier ? [/Résumé]

Bonjour,

Je travaille sur un soft destiné au publique et qui va donc être mis-à-jours (MAJ) de temps en temps.
Pour le "code" en lui-même (je travaille en C# pour l'instant), j'ai des pistes

Par contre, ce projet utilise une base de données locale (Firebird) avec un schéma déjà en place ... mais qui évolue (sinon ce serait trop simple !).

J'ai besoin que l'utilisateur puisse garder son fichier de DB au fur et à mesure des MAJ; il faut donc que je sois capable de modifier celle-ci si besoin.

Je pourrais créer un EXE en ligne de commande qui lance des scripts SQL que je livrerais à chaque MAJ; mais il se pose au moins le problème d'un "saut" de MAJ (de la 1.3 à la 1.7 ou même la 2.1 directement).


J'aime bien l'idée de réutiliser le travail de quelqu'un qui sait mieux faire que moi (s'il m'en donne le droit !).
Je me dis aussi que je ne suis pas le seul à avoir cette problématique... et qu'il doit donc bien exister, si ce n'est des lib qui s'occupent de ça à ma place (je préfère me concentrer sur mes problématiques métier), au moins des best practices afin d'éviter les écueils évidents.

MAIS .. je ne sais même pas comment formuler ma recherche pour trouver ça sur le net ou même ici :/


=> Auriez-vous des recommandations ? Des articles, des libs.. n'importe quoi !


Merci d'avance pour vos éclairages

[CinePhil]

Il faudrait commencer par se demander pourquoi le schéma évolue !
C'est en principe rare et uniquement nécessaire en cas d'évolution des besoins couverts par le logiciel qui utilise la BDD.

Si cette évolution de schéma est vraiment nécessaire, un script SQL peut être augmenté au fur et à mesure des versions et s'il faut sauter d'une version 1 à une version 3 ben le script contient les màj successives et les fait exécuter.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
-- Màj de V1 vers V2
-- les requêtes SQL nécessaires à l'évolution

-- Màj de V2 vers V3
-- les requêtes SQL nécessaires à l'évolution

[ElTchoupi]

Yes tout à fait !

Le schéma évolue pour 2 raisons:
1) Parce que le projet vit: je viens de commencer la version 2 et j'ai déjà quelques changements de modèle. Mais J'ai besoin que mes beta-testeurs puissent conserver leurs bases et que si, lors d'une MAJ, j'ai besoin de modifier le schéma, je puisse le faire !

2) Pour des raisons métier, j'ai besoin de pouvoir créer des tables pour l'ajout de fonctionnalités

Je suis en train de partir sur un système de load de scripts SQL à executer direct sur la base Firebird (la classe FbScript pour info)
Mais j'avoue que je m'y casse un peu les dents là.... (une sombre histoire de "The type of the SQL statement could not be determinated", j'aime pas quand il devient vulgaire, surtout quand ça veut rien dire ).

Mais ensuite, comment vérifier si le schéma correspond à telle ou telle "version" ?
Les DB ne sont pas mon point fort mais d'instinct j'ai pas envie de créer une table SCHEMA_INFOS avec une seule ligne et la version du schema dans une colonne ... Mauvaise intuition ?

J'ai peur de devoir me faire beaucoup de SQL pour (finalement) assez peu de modif ...

Merci encore !