Ho visto che non so in quanti modi ha provato a gestirlo, e alla fine penso che tu debba solo mantenere gli script manuali.
Ora, non devi necessariamente scrivere tu stesso. In MSSQL, mentre stai apportando una modifica, c'è un piccolo pulsante per Genera script, che sputerà uno script SQL per la modifica che stai apportando. So che stai parlando di Oracle e sono passati alcuni anni da quando ho lavorato con la loro GUI, ma posso solo immaginare che abbiano la stessa funzionalità.
Tuttavia, non puoi evitare di lavorare manualmente con gli script. Avrai molti problemi con i dati preesistenti, come i valori predefiniti per le nuove colonne o come gestire i dati per una colonna rinominata/cancellata/spostata. Questa è solo una parte dell'analisi nel lavorare con uno schema di database nel tempo da cui non puoi scappare. Se provi a farlo con una soluzione completamente automatizzata, i tuoi dati prima o poi verranno incasinati.
L'unica cosa che consiglierei, solo per semplificarti la vita, è assicurarti di separare le modifiche allo schema dalle modifiche al codice. La differenza è che le modifiche dello schema alle tabelle e alle colonne devono essere eseguite esattamente una volta e mai più, e quindi devono essere versionate come singoli script di modifica. Tuttavia, le modifiche al codice, come i processi archiviati, le funzioni e persino le viste, possono (e dovrebbero) essere ripetute più e più volte e possono essere modificate come qualsiasi altro file di codice. L'approccio migliore a questo che ho visto è stato quando avevamo tutti i processi/funzioni/viste in VSS e il nostro processo di compilazione li eliminava tutti e li ricreava durante ogni aggiornamento. Questa è la stessa idea di una ricostruzione del tuo codice C#/Java/qualunque cosa, perché assicura che tutto sia sempre aggiornato.
