He visto no sé cuántas formas de manejar esto y, al final, creo que solo necesitas mantener los scripts manuales.
Ahora, no necesariamente tienes que escribir tú mismo. En MSSQL, mientras realiza un cambio, hay un pequeño botón para Generar secuencia de comandos, que arrojará una secuencia de comandos SQL para el cambio que está realizando. Sé que estás hablando de Oracle, y han pasado algunos años desde que trabajé con su GUI, pero solo puedo imaginar que tienen la misma función.
Sin embargo, no puede dejar de trabajar con scripts manualmente. Vas a tener muchos problemas con los datos preexistentes, como los valores predeterminados para las nuevas columnas o cómo manejar los datos de una columna renombrada/eliminada/movida. Esto es solo parte del análisis al trabajar con un esquema de base de datos a lo largo del tiempo del que no puede escapar. Si intenta hacer esto con una solución completamente automatizada, sus datos se estropearán tarde o temprano.
Lo único que recomendaría, solo para hacer su vida un poco más fácil, es asegurarse de separar los cambios de esquema de los cambios de código. La diferencia es que los cambios de esquema en tablas y columnas deben ejecutarse exactamente una vez y nunca más y, por lo tanto, deben versionarse como scripts de cambio individuales. Sin embargo, los cambios de código, como los procesos almacenados, las funciones e incluso las vistas, pueden (y deben) ejecutarse una y otra vez, y pueden versionarse como cualquier otro archivo de código. El mejor enfoque que he visto para esto fue cuando teníamos todos los procesos/funciones/vistas en VSS, y nuestro proceso de compilación descartaba todo y los recreaba durante cada actualización. Esta es la misma idea que hacer una reconstrucción de su código C#/Java/cualquiera que sea, porque se asegura de que todo esté siempre actualizado.
