J'ai vu je-ne-sais-combien-de-façons essayé de gérer cela, et en fin de compte, je pense que vous devez simplement maintenir des scripts manuels.
Maintenant, vous n'avez pas nécessairement à écrire vous-même. Dans MSSQL, lorsque vous apportez une modification, il y a un petit bouton pour générer un script, qui crachera un script SQL pour la modification que vous apportez. Je sais que vous parlez d'Oracle, et cela fait quelques années que je n'ai pas travaillé avec leur interface graphique, mais je ne peux qu'imaginer qu'ils ont la même fonctionnalité.
Cependant, vous ne pouvez pas vous passer de travailler manuellement avec des scripts. Vous allez avoir beaucoup de problèmes avec les données préexistantes, comme les valeurs par défaut pour les nouvelles colonnes ou la façon de gérer les données pour une colonne renommée/supprimée/déplacée. Ce n'est qu'une partie de l'analyse de l'utilisation d'un schéma de base de données au fil du temps dont vous ne pouvez pas vous passer. Si vous essayez de le faire avec une solution entièrement automatisée, vos données seront tôt ou tard gâchées.
La seule chose que je recommanderais, juste pour vous faciliter la vie, est de vous assurer de séparer les changements de schéma des changements de code. La différence est que les modifications de schéma apportées aux tables et aux colonnes doivent être exécutées exactement une fois et plus jamais, et doivent donc être versionnées en tant que scripts de modification individuels. Cependant, les modifications de code, telles que les procédures stockées, les fonctions et même les vues, peuvent (et doivent) être exécutées encore et encore et peuvent être versionnées comme n'importe quel autre fichier de code. La meilleure approche que j'ai vue pour cela était lorsque nous avions tous les procs/fonctions/vues dans VSS, et notre processus de construction supprimait tout et les recréait à chaque mise à jour. C'est la même idée que de reconstruire votre code C#/Java/quel que soit, car cela garantit que tout est toujours à jour.
