Ich habe eine Ich-weiß-nicht-wie-viele-Methoden gesehen, die versucht haben, damit umzugehen, und am Ende denke ich, dass Sie nur manuelle Skripte pflegen müssen.
Nun, Sie müssen dann nicht unbedingt selbst schreiben. Wenn Sie in MSSQL eine Änderung vornehmen, gibt es eine kleine Schaltfläche zum Generieren von Skripts, die ein SQL-Skript für die von Ihnen vorgenommene Änderung ausspuckt. Ich weiß, dass Sie von Oracle sprechen, und es ist ein paar Jahre her, seit ich mit ihrer GUI gearbeitet habe, aber ich kann mir nur vorstellen, dass sie die gleiche Funktion haben.
Allerdings kommt man nicht umhin, manuell mit Skripten zu arbeiten. Sie werden viele Probleme mit bereits vorhandenen Daten haben, z. B. Standardwerte für neue Spalten oder den Umgang mit Daten für eine umbenannte/gelöschte/verschobene Spalte. Dies ist nur ein Teil der Analyse bei der Arbeit mit einem Datenbankschema im Laufe der Zeit, dem Sie nicht entkommen können. Wenn Sie versuchen, dies mit einer vollständig automatisierten Lösung zu tun, werden Ihre Daten früher oder später durcheinander gebracht.
Das einzige, was ich empfehlen würde, um Ihnen das Leben ein wenig einfacher zu machen, ist sicherzustellen, dass Sie Schemaänderungen von Codeänderungen trennen. Der Unterschied besteht darin, dass Schemaänderungen an Tabellen und Spalten genau einmal und nie wieder ausgeführt werden müssen und daher als einzelne Änderungsskripte versioniert werden müssen. Codeänderungen, wie Stored Procs, Funktionen und sogar Ansichten, können (und sollten) jedoch immer wieder ausgeführt und wie jede andere Codedatei versioniert werden. Der beste Ansatz dafür, den ich gesehen habe, war, als wir alle Prozesse/Funktionen/Ansichten in VSS hatten und unser Build-Prozess alle fallen ließ und sie bei jedem Update neu erstellte. Dies ist die gleiche Idee wie eine Neuerstellung Ihres C#/Java/was auch immer-Codes, da dadurch sichergestellt wird, dass alles immer auf dem neuesten Stand ist.
