Ich versuche, ein wiederverwendbares System für die Versionierung von Datenbankschemata in PHP-Projekten zu finden.

Es gibt eine Reihe von Rails-ähnlichen Migrationsprojekten für PHP.http: //code.google.com/p/mysql-php-migrations ist ein gutes Beispiel. Es verwendet Zeitstempel für Migrationsdateien, was bei Konflikten zwischen Zweigen hilft.

Allgemeines Problem mit dieser Art von System: Wenn Entwicklungszweig A ausgecheckt ist und Sie stattdessen Zweig B auschecken möchten, enthält B möglicherweise neue Migrationsdateien. Dies ist in Ordnung, die Migration auf neuere Inhalte ist unkompliziert.

Wenn Zweig A über neuere Migrationsdateien verfügt, müssen Sie abwärts zum nächsten freigegebenen Patch migrieren. Wenn Zweig A und B erheblich unterschiedliche Codebasen haben, müssen Sie möglicherweise noch weiter nach unten migrieren. Dies kann Folgendes bedeuten: Auschecken von B, Ermitteln der freigegebenen Patch-Nummer, Auschecken von A und Abwärtsmigration auf diesen Patch. Dies muss von A aus erfolgen, da die tatsächlich angewendeten Patches in B nicht verfügbar sind. Überprüfen Sie dann Zweig B und migrieren Sie auf das neueste B-Patch. Kehren Sie den Vorgang erneut um, wenn Sie von B nach A wechseln.

Vorgeschlagenes System: Wenn Sie aufwärts migrieren, anstatt nur die Patch-Version zu speichern, serialisieren Sie den gesamten Patch für die spätere Verwendung in der Datenbank, obwohl ich wahrscheinlich nur die down () -Methode benötigen würde. Vergleichen Sie beim Ändern von Zweigen ausgeführte Patches mit Patches, die im Zielzweig verfügbar sind. Bestimmen Sie den nächsten gemeinsamen Patch (oder vielleicht den ältesten Unterschied) zwischen der DB-Tabelle der ausgeführten Patches und den Patches im Zielzweig nach ID oder Hash. Es kann auch nach neuen oder fehlenden Patches gesucht werden, die unter mehreren gemeinsam genutzten Patches zwischen den beiden Zweigen vergraben sind.

Mischen Sie den Patch automatisch mit den Methoden von db table saved down () zum nächsten gemeinsam genutzten Patch und führen Sie ihn dann mit dem neuesten Patch der Branche zusammen.

Meine Frage ist Ist dieses System zu verrückt und / oder mit Konsequenzen behaftet, um sich die Mühe zu machen, es zu entwickeln? Meine Erfahrung mit der Versionierung von Datenbankschemas beschränkt sich auf PHP-Autopatch, ein System, das nur up () - Dateien mit sequentiellen IDs benötigt.

Update, 2 Jahre später

Dies ist ein alter Beitrag, aber ich wollte erwähnen, dass ich Migrationen im Allgemeinen während der Entwicklung aufgegeben habe, da sie unnötig kompliziert und fehleranfällig sind.

Stattdessen verwende ich Build-Skripte, um:

leere die Datenbank,Erstelle das Schema,add bekannte Anwendungsdaten (echter Inhalt) undAdd Fixture Data (Entwicklungsinhalt).

Wenn Sie einen Zweig wechseln oder Aktualisierungen von anderen Entwicklern erhalten, laden Sie die Datenbank mit einem einzigen Befehl vollständig neu, um einen bekannten Status zu erhalten.

Produktionsserver benötigen weiterhin Datenbank-Patches, diese müssten jedoch trotzdem manuell erstellt werden.