Tant de gens essaient de faire ce genre de choses (schémas diff). Mon avis est
- Le code source va dans un outil de contrôle de version (Subversion, CSV, GIT, Perforce...). Traitez-le comme s'il s'agissait de code Java ou C, ce n'est vraiment pas différent. Vous devriez avoir un processus d'installation qui le vérifie et l'applique à la base de données.
- DDL EST LE CODE SOURCE. Il entre également dans l'outil de contrôle de version.
- Les données sont une zone grise - les tables de recherche devraient peut-être se trouver dans un outil de contrôle de version. Les données générées par l'application ne le devraient certainement pas.
La façon dont je fais les choses ces jours-ci est de créer des scripts de migration similaires aux migrations Ruby on Rails. Mettez votre DDL dans des scripts et exécutez-les pour déplacer la base de données entre les versions. Regroupez les modifications d'une version dans un seul fichier ou ensemble de fichiers. Ensuite, vous avez un script qui déplace votre application de la version x à la version y.
Une chose que je ne fais plus jamais (et je le faisais jusqu'à ce que j'apprenne mieux) est d'utiliser n'importe quel outil graphique pour créer des objets de base de données dans mon environnement de développement. Écrivez les scripts DDL dès le premier jour - vous en aurez de toute façon besoin pour promouvoir le code à tester, produire, etc. des scripts pour créer/migrer correctement le schéma qui souvent ne sont pas testés et échouent !
Chacun aura sa propre préférence quant à la façon de procéder, mais j'ai vu beaucoup de choses mal faites au fil des ans, ce qui a formé mon opinion ci-dessus.
