Jeg har set jeg-ved-ikke-hvor-mange måder at håndtere dette på, og i sidste ende tror jeg, at du bare skal vedligeholde manuelle scripts.
Nu behøver du ikke nødvendigvis selv at skrive. I MSSQL, mens du laver en ændring, er der en lille knap til at generere script, som vil spytte et SQL-script ud for den ændring, du laver. Jeg ved, du taler om Oracle, og det er et par år siden, jeg arbejdede med deres GUI, men jeg kan kun forestille mig, at de har den samme funktion.
Du kan dog ikke komme væk fra at arbejde med scripts manuelt. Du kommer til at have en masse problemer omkring allerede eksisterende data, som standardværdier for nye kolonner eller hvordan man håndterer data for en omdøbt/slettet/flyttet kolonne. Dette er blot en del af analysen i at arbejde med et databaseskema over tid, som man ikke kan komme væk fra. Hvis du forsøger at gøre dette med en fuldstændig automatiseret løsning, vil dine data blive rodet sammen før eller siden.
Den ene ting, jeg vil anbefale, bare for at gøre dit liv lidt lettere, er at sørge for at adskille skemaændringer fra kodeændringer. Forskellen er, at skemaændringer til tabeller og kolonner skal køres nøjagtigt én gang og aldrig igen, og derfor skal versioneres som individuelle ændringsscripts. Kodeændringer, såsom lagrede processer, funktioner og endda visninger, kan (og bør) køres igen og igen og kan versioneres ligesom enhver anden kodefil. Den bedste tilgang til dette, jeg har set, var, da vi havde alle procs/funktioner/visninger i VSS, og vores byggeproces ville droppe alle og og genskabe dem under hver opdatering. Dette er den samme idé som at lave en genopbygning af din C#/Java/whatever-kode, fordi det sørger for, at alt altid er opdateret.