So viele Leute versuchen so etwas (Diff-Schemata). Meine Meinung ist
- Quellcode geht in ein Versionskontrolltool (Subversion, CSV, GIT, Perforce ...). Behandeln Sie es so, als wäre es Java- oder C-Code, es ist wirklich nicht anders. Sie sollten einen Installationsprozess haben, der es auscheckt und auf die Datenbank anwendet.
- DDL IST QUELLCODE. Es geht auch in das Versionskontrolltool.
- Daten sind eine Grauzone - Nachschlagetabellen sollten vielleicht in einem Versionskontrolltool enthalten sein. Anwendungsgenerierte Daten sollten dies sicherlich nicht.
Heutzutage erstelle ich Migrationsskripte ähnlich wie bei Ruby on Rails-Migrationen. Fügen Sie Ihre DDL in Skripts ein und führen Sie sie aus, um die Datenbank zwischen Versionen zu verschieben. Gruppieren Sie Änderungen für eine Version in einer einzelnen Datei oder einem Satz von Dateien. Dann haben Sie ein Skript, das Ihre Anwendung von Version x auf Version y verschiebt.
Eine Sache, die ich nie mehr mache (und ich habe es früher getan, bis ich es besser gelernt habe), ist die Verwendung von GUI-Tools zum Erstellen von Datenbankobjekten in meiner Entwicklungsumgebung. Schreiben Sie die DDL-Skripte von Tag 1 an - Sie werden sie sowieso brauchen, um den Code zum Testen, Produzieren usw. zu fördern. Ich habe so viele Leute gesehen, die die GUIs verwenden, um alle Objekte zu erstellen, und zum Zeitpunkt der Veröffentlichung gibt es ein Scrabble, das versucht werden soll, zu produzieren Skripte zur korrekten Erstellung/Migration des Schemas, die oft nicht getestet werden und fehlschlagen!
Jeder wird seine eigenen Vorlieben haben, wie man das macht, aber ich habe im Laufe der Jahre viel davon gesehen, was schlecht gemacht wurde, was meine obige Meinung gebildet hat.
