Beginnend mit der Versionierung von MySQL-Schemata ohne Overkill. Gute Lösungen?

Ich denke, diese Frage verdient eine moderne Antwort, also werde ich sie mir selbst geben. Als ich die Frage im Jahr 2009 geschrieben habe, glaube ich nicht, dass Phinx bereits existierte und Laravel definitiv nicht.

Heute ist die Antwort auf diese Frage sehr klar: Schreibe inkrementelle DB-Migrationsskripte mit jeweils einer up - und einer down -Methode und führe all diese Skripte oder ein Delta davon aus, wenn du deine App installierst oder aktualisierst. Und fügen Sie natürlich die Migrationsskripte zu Ihrem VCS hinzu.

Wie bereits erwähnt, gibt es heute in der PHP-Welt hervorragende Werkzeuge, mit denen Sie Ihre Migrationen einfach verwalten können. Laravel verfügt über integrierte DB-Migrationen einschließlich der entsprechenden Shell-Befehle. Jeder andere hat eine ähnlich leistungsstarke Framework-Agnostic-Lösung mit Phinx.

Sowohl Artisan Migrationen (Laravel) als auch Phinx funktionieren gleich. Erstellen Sie für jede Änderung in der DB eine neue Migration, verwenden Sie Plain SQL oder den integrierten Abfrage-Generator, um die Hoch- und Runtermethoden zu schreiben, und führen Sie artisan migrate bzw. phinx migrate in der Konsole.

Einfacher Weg für ein kleines Unternehmen: Speichern Sie Ihre Datenbank in SQL und fügen Sie sie Ihrem Repository hinzu. Fügen Sie dann jedes Mal, wenn Sie etwas ändern, die Änderungen in der Dump-Datei hinzu.

Sie können dann diff verwenden, um Änderungen zwischen den Versionen zu sehen, ganz zu schweigen von Kommentaren, die Ihre Änderungen erklären. Dies macht Sie auch praktisch immun gegen MySQL-Upgrades.

Der einzige Nachteil, den ich gesehen habe, ist, dass Sie daran denken müssen, das SQL manuell zu Ihrer Dump-Datei hinzuzufügen. Du kannst dich trainieren, dich immer daran zu erinnern, aber sei vorsichtig, wenn du mit anderen arbeitest. Ein Update zu verpassen könnte später ein Problem sein.

Dies könnte gemildert werden, indem man ein ausgeklügeltes Skript erstellt, um es für dich zu tun, wenn du Subversion einreichst, aber es ist ein bisschen viel für eine Ein-Mann-Show.

Bearbeiten: In dem Jahr, das seit dieser Antwort vergangen ist, musste ich ein Versionsschema für MySQL für ein kleines Team implementieren. Das manuelle Hinzufügen jeder Änderung wurde als umständliche Lösung angesehen, ähnlich wie es in den Kommentaren erwähnt wurde. Daher haben wir die Datenbank gedumpt und diese Datei der Versionskontrolle hinzugefügt.

Was wir herausfanden, war, dass die Testdaten in der Müllkippe landeten und es ziemlich schwierig machte, herauszufinden, was sich geändert hatte. Dies könnte nur durch Dumping des Schemas gelöst werden, aber dies war für unsere Projekte nicht möglich, da unsere Anwendungen davon abhängig waren, dass bestimmte Daten in der Datenbank funktionierten. Schließlich kehrten wir zu dem manuellen Hinzufügen von Änderungen zu dem Datenbank-Abbild zurück.

Dies war nicht nur die einfachste Lösung, sondern löste auch einige Probleme, die einige Versionen von MySQL beim Exportieren / Importieren haben. Normalerweise müssten wir die Entwicklungsdatenbank auslagern, Testdaten entfernen, Einträge protokollieren usw., ggf. bestimmte Namen entfernen / ändern und erst dann die Produktionsdatenbank erstellen. Durch das manuelle Hinzufügen von Änderungen konnten wir genau kontrollieren, was genau in der Produktion enden würde, so dass am Ende alles bereit war und der Umzug in die Produktionsumgebung so schmerzlos wie möglich war.

Wie wäre es mit einer Versionsdatei, die dadurch erzeugt wird:

Wo ich arbeite, haben wir ein Installationsskript für jede neue Version der App, die die SQL hat, die wir für das Upgrade ausführen müssen. Dies funktioniert gut genug für 6 Entwickler mit einigen Verzweigungen für Wartungsversionen. Wir ziehen in Erwägung, zu Auto Patch Ссылка zu wechseln, um herauszufinden, welche Patches für die zu aktualisierende Datenbank gelten. Es sieht so aus, als ob es eine kleine Komplikation geben könnte, die Verzweigung mit automatischem Patch behandelt, aber es klingt nicht so, als wäre das ein Problem für dich.

Ich würde raten, eine Batch-Datei wie diese sollte den Job machen (nicht hart zu tun) ...

  

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

einfach die Batch-Datei nach dem Ändern des Schemas, oder lassen Sie es von einem Cron / Scheduler tun (aber ich weiß nicht ... ich denke, commits Arbeit, wenn nur die Zeitstempel geändert, auch wenn der Inhalt der gleiche ist. weiß nicht, ob das ein Problem wäre.)

Die wichtigste Idee ist, einen Ordner mit dieser Struktur in Ihrem Projektbasispfad zu haben

Nun, wer die ganze Sache funktioniert, ist, dass Sie 3 Ordner haben: Tabellen Hält die Tabellenerstellungsabfrage. Ich empfehle die Benennung "table_name.sql".

Daten Hält die Tabelleneinfügedatenabfrage. Ich empfehle die gleiche Benennung "table_name.sql". Hinweis: Nicht alle Tabellen benötigen eine Datendatei, sondern nur diejenigen, die diese Initialdaten für die Projektinstallation benötigen.

Änderungsmengen Dies ist der Hauptordner, mit dem Sie arbeiten werden. Dies enthält die Änderungssets, die an der Anfangsstruktur vorgenommen wurden. Dies beinhaltet eigentlich Ordner mit Changesets. Zum Beispiel habe ich einen Ordner 1123 hinzugefügt, der die Änderungen enthält, die in Revision 1123 vorgenommen wurden (die Nummer stammt von Ihrem Code-Quellcode-Steuerelement) und kann eine oder mehrere SQL-Dateien enthalten.

Ich möchte sie gruppiert in Tabellen mit der Benennung xx_tablename.sql hinzufügen - die xx ist eine Zahl, die die Reihenfolge angibt, die sie ausgeführt werden müssen, da manchmal die Änderung in einer bestimmten Reihenfolge ausgeführt werden muss.

Hinweis: Wenn Sie eine Tabelle ändern, fügen Sie diese Änderungen auch zu Tabellen- und Datendateien hinzu, da dies die Dateien sind, die für eine Neuinstallation verwendet werden.

Dies ist die wichtigste Idee.

Für weitere Details können Sie diesen Blogeintrag

Sehen Sie sich SchemaSync an. Es generiert die Patch- und Reverse-Skripte (.sql-Dateien), die für die Migration und Versionierung Ihres Datenbankschemas benötigt werden. Es ist ein Befehlszeilendienstprogramm für MySQL, das sprach- und rahmenunabhängig ist.

Unsere Lösung ist MySQL Workbench. Wir entwickeln die vorhandene Datenbank regelmäßig zu einem Model mit der entsprechenden Versionsnummer zurück. Es ist dann möglich, Diffs nach Bedarf einfach zwischen Versionen auszuführen. Außerdem erhalten wir schöne EER-Diagramme usw.

Ich mache etwas ähnliches wie Manos, außer dass ich eine "Master" -Datei (master.sql) habe, die ich mit einiger Regelmäßigkeit aktualisiere (einmal alle 2 Monate). Dann erstelle ich für jede Änderung eine Version namens .sql-Datei mit den Änderungen. Auf diese Weise kann ich mit der Datei master.sql beginnen und jede Version namens .sql-Datei hinzufügen, bis ich die aktuelle Version erhalte und ich Clients mit der Version namens .sql-Dateien aktualisieren kann, um die Dinge zu vereinfachen.