Versionning Base de données

Bonjour à tous,
J'ai un petite question, concernant le versionning de projet, qui m'embête un peu.

Imaginons qu'on est un projet plutôt classique constitué d'une base de données et de code qui exploite cette base.
Pour faire ça propre on utilise un SCM pour versionner son code, bosser à plusieurs dessus...
Mais comment fait-on pour gérer les versions de sa base de données (où schéma Oracle,etc...) ?
En théorie, au fur et à mesure que le code évolue, il y a de grande chance pour que notre base évolue avec (ajout de table, de champs, de contraintes...). Or où est l'intérêt de gérer les différentes versions de notre code si on ne gère pas celles de notre BDD. Parce que dans ce cas si pour X raisons, on décide de revenir à une version antérieur, c'est cuit, car notre base ne correspondra plus au code.

OK dans un contexte POO, si on fait des classes qui map les tables de notre base, normalement il ne doit y avoir que peu de code impacté mais quand même.

Il me semble qu'il s'agit d'un problème assez important et je me demande pourquoi on en parle si peu dans les tutos sur l'utilisation de SCM.

Pour l'instant je n'ai pas trouvé de solution réellement convaincante à mon gout :
- faire des exports SQL de l'architecture (CREATE TABLE, ALTER...) de ma base et versionner ces fichiers avec un SCM type CVS ou Subversion
- il existe des outils payants que je n'ai pas pu tester, un fait par QuestSoftware pour Oracle -> Toad Data Modeler et un autre de Microsoft pour SQLServer (j'ai oublié le nom).

J'aimerais avoir vos avis et vos méthodes sur la question.

Moi je penserais de faire un versionning sur les sauvegardes des BDD .

Par concéquent en cas de fausse manipulation ou quoi que ce soit on peut retourner a une base de donnée.

C'est long est fastidieux mais c'est bien pratique en cas de problème .

Sinon tu peux te faire des fichiers contenant les données de tes bases (par exemple en XML), et tu te construis un impoter et un exporter qui se charge de charger et exporter tes données de la base.
Il ne te reste plus qu'a versionner tes fichiers XML.
Après à toi de voir la logique de tes fichiers, par exemples un fichier par table.

tu veux versionner juste le schéma ou aussi les données avec ?

dans le second cas, si tu sais où sont placés les fichiers de ta base, on pourrait aussi imaginer que tu les mettes carrément dans ton outil de SCM, non ? Ca nécessitera à priori d'arrêter la base pour avoir un état stable.

A priori, il s'agit surtout de versionner le schéma.

Après reflexion, je pense que je choisirai la méthode d'export en requêtes SQL dans un fichier puis versionning du fichier. Mais ça suppose juste de bien penser à le faire à chaque fois. Il me semble que ça ne doit pas être trop difficile de prévoir un outil qui le fasse de manière automatique en lui précisant les identifiants de la base.

En tout cas, merci pour vos réponses.

Bonjour,

dans notre cas, on utilise CVS aussi bien pour la gestion du code source (delphi en l'occurence) de l'application que du "code source" de la base de données extraction des tables, des procédures, ... et des données de paramètres en SQL.

De cette manière, t'as le source Base de données et le code applicatif qui évolue en même temps

A+

Exactement le sujet que je cherchais,

Pour l'instant ce que nous avons mis en place c'est le versioning de la structure et des données d'initialisation en sql.

La prochaine étape c'est de versioner le mcd (modèle conceptuel).

La question qui se pose, c'est comment ensuite migrer facilement la base de données de production à partir de ces ressources versionnées (structure et données) ?

Ce à quoi je pensais, c'est d'avoir un outil (à déterminer) qui génère automatiquement un script de mise à jour en comparant 2 révisions des scripts sql, mais la je touche un peu à une autre problématique.

Ce qu'il faut faire c'est bien entendu versionner le ou les fichiers qui te permettent de créer ton schéma de base.
Soit tu as modélisé ta base et tu versionnes les fichiers de l'outil de modélisation (on fait cela avec Rose, RDA,...) ou bien tu créés des scripts de création/mise à jour du schéma (CREATE TABLE, CREATE VIEW, ...) et tu versionnes ces scripts.

Si tu as besoin de versionner des données de référence contenues dans tes tables et bien tu fais pareil (scripts INSERT INTO....)

Citation:

---

Envoyé par ego

Ce qu'il faut faire c'est bien entendu versionner le ou les fichiers qui te permettent de créer ton schéma de base.
Soit tu as modélisé ta base et tu versionnes les fichiers de l'outil de modélisation (on fait cela avec Rose, RDA,...) ou bien tu créés des scripts de création/mise à jour du schéma (CREATE TABLE, CREATE VIEW, ...) et tu versionnes ces scripts ...

---

Pour le DDL d'une table ce n'est pas aussi simple que ça cher collègue ...

Sauf à détruire et à re-créer (DROP / CREATE) la table à chaque fois, ce qui pour une table de 100 millions de lignes accédée 24h/24 7j/7 n'est pas très pratique, on en conviendra, on travaille la plupart de temps par différence.
C'est à dire qu'on modifie (ALTER), pour ajouter une colonne par exemple, la structure existante.

L'approche en terme de GCL/SCM commence à se compliquer singulièrement ...

Cher collègue, comme tu le dis,

J'ai mis entre parenthèses "CREATE, ..." car je ne voulais pas tout lister. Allons y donc...

En effet, à part la première version du script qui contient probablement "que" des CREATE" (première version = première version de la base mise en prod), les autres versions contiendront des "ALTER" et des "CREATE".
Ceci dit, quand on modélise la base avec PowerAMC ou RDA ou Erwin ou...on fait bien du versioning de l'ensemble du modèle. Ce n'est que lorsque l'on demande à créer le DDL que les outils nous aident à faire un DIFF entre la version mise en prod et la version que l'on veut déployer. Ce DIFF permet de créer le script "d'altération" du schéma existant. Le changement de schéma pouvant être in fine plus complexe que cela encore car des "migrations" de données peuvent être à réaliser.
Ceci dit, pour créer une nouvelle plate-forme de test, il faudra dans certains cas créer le script avec uniquement les "CREATE" car sur cette plate-forme il n'y a pas la base version "N-1" ou parce que l'on veut avant tout tester la nouvelle version avant même de faire le test complet de la migration de N-1 vers N.

Donc au final, il faut bien versionner chaque version complète du schéma.

Bonsoir,

Ayant été confrontés à cette même problématique maintes et maintes fois, un projet open source a vu le jour pour mieux y répondre.

Il s'agit d'un IDE de développement pour bases de données (Oracle, Mysql, Postgresql) permettant notamment de gérer le versioning de structures de données. Il permet également de traquer toute modification effectuée sur votre modèle au fil du temps et de générer automatiquement les scripts de livraison SQL.

Les scripts peuvent être utilisés tels quel ou bien être embarqués dans un livrable déployable via un installateur (également gratuit) permettant de déployer les livrables avec vérification des versions précédentes, validation structurelle après l'installation, etc.

Je vous invite à découvrir cela sur :
http://www.nextep-softwares.fr
et
http://www.nextep-softwares.com

L'IDE est basé sur Eclipse RCP et permettra donc aux fans de Java de rapidement s'y retrouver. Cela permet également un support de Windows, Linux et Mac.