Mechanismen zum Verfolgen von DB-Schemaänderungen [geschlossen]

https://stackoverflow.com/questions/1607

08-06-2019
|

Frage

Was sind die besten Methoden zum Verfolgen und/oder Automatisieren von DB-Schemaänderungen?Unser Team verwendet Subversion zur Versionskontrolle und wir konnten auf diese Weise einige unserer Aufgaben automatisieren (Builds auf einen Staging-Server übertragen, getesteten Code auf einem Produktionsserver bereitstellen), aber wir führen Datenbankaktualisierungen immer noch manuell durch.Ich möchte eine Lösung finden oder erstellen, die es uns ermöglicht, effizient über Server mit unterschiedlichen Umgebungen hinweg zu arbeiten und gleichzeitig Subversion weiterhin als Backend zu verwenden, über das Code- und DB-Updates an verschiedene Server weitergegeben werden.

Viele gängige Softwarepakete enthalten Skripte für die automatische Aktualisierung, die die DB-Version erkennen und die erforderlichen Änderungen vornehmen.Ist dies auch in größerem Maßstab (über mehrere Projekte und manchmal mehrere Umgebungen und Sprachen hinweg) der beste Weg, dies zu tun?Wenn ja, gibt es vorhandenen Code, der den Prozess vereinfacht, oder ist es am besten, einfach unsere eigene Lösung zu implementieren?Hat jemand schon einmal etwas Ähnliches implementiert und in Subversion-Post-Commit-Hooks integriert, oder ist das eine schlechte Idee?

Während eine Lösung, die mehrere Plattformen unterstützt, vorzuziehen wäre, müssen wir auf jeden Fall den Linux/Apache/MySQL/PHP-Stack unterstützen, da der Großteil unserer Arbeit auf dieser Plattform stattfindet.

Lösung

In der Rails-Welt gibt es das Konzept von Migrationen, Skripten, bei denen Änderungen an der Datenbank in Ruby und nicht in einer datenbankspezifischen Variante von SQL vorgenommen werden.Ihr Ruby-Migrationscode wird schließlich in die für Ihre aktuelle Datenbank spezifische DDL konvertiert.Dies macht den Wechsel der Datenbankplattform sehr einfach.

Für jede Änderung, die Sie an der Datenbank vornehmen, schreiben Sie eine neue Migration.Migrationen erfolgen typischerweise auf zwei Arten:eine „Up“-Methode, bei der die Änderungen übernommen werden, und eine „Down“-Methode, bei der die Änderungen rückgängig gemacht werden.Ein einzelner Befehl bringt die Datenbank auf den neuesten Stand und kann auch verwendet werden, um die Datenbank auf eine bestimmte Version des Schemas zu bringen.In Rails werden Migrationen in einem eigenen Verzeichnis im Projektverzeichnis gespeichert und wie jeder andere Projektcode in die Versionskontrolle eingecheckt.

Dieser Oracle-Leitfaden für Rails-Migrationen deckt Migrationen recht gut ab.

Entwickler, die andere Sprachen verwenden, haben sich mit Migrationen befasst und ihre eigenen sprachspezifischen Versionen implementiert.Ich weiß von Aufruhr, ein PHP-Migrationssystem, das den Migrationen von Rails nachempfunden ist;Es könnte das sein, wonach Sie suchen.

Andere Tipps

Wir verwenden etwas Ähnliches wie bcwoord, um unsere Datenbankschemata über fünf verschiedene Installationen (Produktion, Staging und einige Entwicklungsinstallationen) hinweg synchron zu halten und in der Versionskontrolle zu sichern, und es funktioniert ziemlich gut.Ich werde etwas näher darauf eingehen:

Um die Datenbankstruktur zu synchronisieren, verfügen wir über ein einziges Skript, update.php, und eine Reihe von Dateien mit den Nummern 1.sql, 2.sql, 3.sql usw.Das Skript verwendet eine zusätzliche Tabelle, um die aktuelle Versionsnummer der Datenbank zu speichern.Die N.sql-Dateien werden von Hand erstellt, um von Version (N-1) zu Version N der Datenbank zu gelangen.

Sie können verwendet werden, um Tabellen hinzuzufügen, Spalten hinzuzufügen, Daten von einem alten in ein neues Spaltenformat zu migrieren und dann die Spalte zu löschen, „Master“-Datenzeilen wie Benutzertypen einzufügen usw.Im Grunde kann es alles, und mit geeigneten Datenmigrationsskripten werden Sie nie Daten verlieren.

Das Update-Skript funktioniert folgendermaßen:

Stellen Sie eine Verbindung zur Datenbank her.

Erstellen Sie ein Backup der aktuellen Datenbank (weil Sachen Wille schief gehen) [mysqldump].

Erstellen Sie eine Buchhaltungstabelle (genannt _meta), falls diese nicht vorhanden ist.

Aktuelle VERSION aus der _meta-Tabelle lesen.Nehmen Sie 0 an, wenn nicht gefunden.

Führen Sie alle SQL-Dateien mit einer höheren Nummer als VERSION der Reihe nach aus

Wenn eine der Dateien einen Fehler verursacht hat:Führen Sie einen Rollback zum Backup durch

Andernfalls aktualisieren Sie die Version in der Buchhaltungstabelle auf die höchste ausgeführte SQL-Datei.

Alles geht in die Quellcodeverwaltung und jede Installation verfügt über ein Skript, um mit einer einzigen Skriptausführung (Aufruf von update.php mit dem richtigen Datenbankkennwort usw.) auf die neueste Version zu aktualisieren.Wir aktualisieren Staging- und Produktionsumgebungen per SVN über ein Skript, das automatisch das Datenbankaktualisierungsskript aufruft, sodass ein Code-Update mit den erforderlichen Datenbankaktualisierungen einhergeht.

Wir können dasselbe Skript auch verwenden, um die gesamte Datenbank von Grund auf neu zu erstellen;Wir löschen einfach die Datenbank, erstellen sie neu und führen dann das Skript aus, das die Datenbank vollständig neu füllt.Wir können das Skript auch verwenden, um eine leere Datenbank für automatisierte Tests zu füllen.

Die Einrichtung dieses Systems hat nur wenige Stunden gedauert, es ist konzeptionell einfach und jeder erhält das Versionsnummerierungsschema, und es war von unschätzbarem Wert für die Möglichkeit, das Datenbankdesign voranzutreiben und weiterzuentwickeln, ohne die Änderungen kommunizieren oder manuell ausführen zu müssen auf allen Datenbanken.

Seien Sie jedoch vorsichtig, wenn Sie Abfragen von phpMyAdmin einfügen! Diese generierten Abfragen enthalten normalerweise den Datenbanknamen, was Sie auf keinen Fall wollen, da es Ihre Skripte beschädigen würde!So etwas wie TABELLE ERSTELLEN mydb.newtable(...) schlägt fehl, wenn die Datenbank auf dem System nicht mydb heißt.Wir haben einen SVN-Hook vor dem Kommentieren erstellt, der .sql-Dateien, die das enthalten, nicht zulässt mydb string, was ein sicheres Zeichen dafür ist, dass jemand ohne ordnungsgemäße Überprüfung aus phpMyAdmin kopiert/eingefügt hat.

Mein Team erstellt Skripts für alle Datenbankänderungen und übergibt diese Skripts zusammen mit jeder Version der Anwendung an SVN.Dies ermöglicht inkrementelle Änderungen der Datenbank, ohne dass Daten verloren gehen.

Um von einer Version zur nächsten zu wechseln, müssen Sie lediglich die Änderungsskripts ausführen, und schon ist Ihre Datenbank auf dem neuesten Stand und Sie haben immer noch alle Ihre Daten.Es ist vielleicht nicht die einfachste Methode, aber sie ist definitiv effektiv.

Das Problem hier besteht darin, es Entwicklern wirklich einfach zu machen, ihre eigenen lokalen Änderungen in die Quellcodeverwaltung zu schreiben, um sie mit dem Team zu teilen.Ich bin seit vielen Jahren mit diesem Problem konfrontiert und wurde von der Funktionalität von Visual Studio für Datenbankprofis inspiriert.Wenn Sie ein Open-Source-Tool mit denselben Funktionen wünschen, versuchen Sie Folgendes: http://dbsourcetools.codeplex.com/ Viel Spaß, - Nathan.

Wenn Sie noch nach Lösungen suchen:Wir schlagen ein Tool namens neXtep Designer vor.Es handelt sich um eine Datenbankentwicklungsumgebung, mit der Sie Ihre gesamte Datenbank unter Versionskontrolle stellen können.Sie arbeiten an einem versionierten Repository, in dem jede Änderung nachverfolgt werden kann.

Wenn Sie ein Update veröffentlichen müssen, können Sie Ihre Komponenten festschreiben und das Produkt generiert automatisch das SQL-Upgrade-Skript der vorherigen Version.Natürlich können Sie dieses SQL aus 2 beliebigen Versionen generieren.

Dann haben Sie viele Möglichkeiten:Sie können diese Skripte nehmen und sie mit Ihrem App-Code in Ihr SVN einfügen, damit sie von Ihrem vorhandenen Mechanismus bereitgestellt werden.Eine weitere Möglichkeit besteht darin, den Liefermechanismus von neXtep zu nutzen:Skripte werden in einem sogenannten „Lieferpaket“ (SQL-Skripte + XML-Deskriptor) exportiert, und ein Installer kann dieses Paket verstehen und auf einem Zielserver bereitstellen und dabei strukturelle Konsistenz, Abhängigkeitsprüfung, Registrierung der installierten Version usw. sicherstellen.

Das Produkt ist GPL und basiert auf Eclipse, sodass es unter Linux, Mac und Windows läuft.Derzeit werden auch Oracle, Mysql und Postgresql unterstützt (DB2-Unterstützung ist in Vorbereitung).Schauen Sie sich das Wiki an, dort finden Sie detailliertere Informationen:http://www.nextep-softwares.com/wiki

Speichern Sie Ihr Schema in einer Datei und fügen Sie es der Quellcodeverwaltung hinzu.Dann zeigt Ihnen ein einfacher Diff, was sich geändert hat.

Scott Ambler produziert eine großartige Artikelserie (und ist Co-Autor von u. a.). Buch) zum Datenbank-Refactoring, mit der Idee, dass Sie im Wesentlichen TDD-Prinzipien und -Praktiken auf die Pflege Ihres Schemas anwenden sollten.Sie richten eine Reihe von Struktur- und Seed-Daten-Einheitentests für die Datenbank ein.Bevor Sie dann etwas ändern, ändern/schreiben Sie Tests, um diese Änderung widerzuspiegeln.

Wir machen das jetzt schon eine Weile und es scheint zu funktionieren.Wir haben Code geschrieben, um grundlegende Spaltennamen- und Datentypprüfungen in einer Unit-Testing-Suite zu generieren.Wir können diese Tests jederzeit erneut ausführen, um zu überprüfen, ob die Datenbank im SVN-Checkout mit der Live-Datenbank übereinstimmt, die die Anwendung tatsächlich ausführt.

Wie sich herausstellt, optimieren Entwickler manchmal auch ihre Sandbox-Datenbank und versäumen es, die Schemadatei in SVN zu aktualisieren.Der Code hängt dann von einer Datenbankänderung ab, die nicht eingecheckt wurde.Diese Art von Fehler kann wahnsinnig schwer zu lokalisieren sein, aber die Testsuite erkennt ihn sofort.Dies ist besonders praktisch, wenn Sie es in einen größeren Continuous-Integration-Plan integriert haben.

K.Scott Allen hat ein oder zwei anständige Artikel zur Schemaversionierung, die das Konzept der inkrementellen Aktualisierungsskripte/Migrationen verwenden, auf das in anderen Antworten hier verwiesen wird;sehen http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.

Es ist ein bisschen Low-Tech und es gibt vielleicht eine bessere Lösung, aber Sie könnten Ihr Schema einfach in einem SQL-Skript speichern, das ausgeführt werden kann, um die Datenbank zu erstellen.Ich denke, Sie können einen Befehl ausführen, um dieses Skript zu generieren, aber ich kenne den Befehl leider nicht.

Übertragen Sie dann das Skript zusammen mit dem darauf arbeitenden Code in die Quellcodeverwaltung.Wenn Sie das Schema zusammen mit dem Code ändern müssen, kann das Skript zusammen mit dem Code eingecheckt werden, der das geänderte Schema erfordert.Dann zeigen Unterschiede im Skript Unterschiede bei Schemaänderungen an.

Mit diesem Skript könnten Sie es in DBUnit oder eine Art Build-Skript integrieren, sodass es anscheinend in Ihre bereits automatisierten Prozesse passt.

Wenn Sie C# verwenden, schauen Sie sich Subsonic an, ein sehr nützliches ORM-Tool, das aber auch SQL-Skripte generiert, um Ihr Schema und/oder Ihre Daten neu zu erstellen.Diese Skripte können dann in die Quellcodeverwaltung übernommen werden.

http://subsonicproject.com/

Ich habe die folgende Datenbankprojektstruktur in Visual Studio für mehrere Projekte verwendet und sie hat ziemlich gut funktioniert:

Datenbank

Skripte ändern

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Erstellen Sie Skripte

Sprocs

Funktionen

Ansichten

Unser Build-System aktualisiert dann die Datenbank von einer Version zur nächsten, indem es die Skripte in der folgenden Reihenfolge ausführt:

1.PreDeploy.sql

2.SchemaChanges.sql

Inhalt des Ordners „Skripte erstellen“.

2.DataChanges.sql

3.Permissions.sql

Jeder Entwickler checkt seine Änderungen für einen bestimmten Fehler/ein bestimmtes Feature ein, indem er seinen Code an das Ende jeder Datei anhängt.Sobald eine Hauptversion vollständig und in der Quellcodeverwaltung verzweigt ist, werden die Inhalte der SQL-Dateien im Ordner „Change Scripts“ gelöscht.

Wir verwenden eine sehr einfache, aber dennoch effektive Lösung.

Für Neuinstallationen haben wir eine metadata.sql-Datei im Repository, die das gesamte DB-Schema enthält. Im Build-Prozess verwenden wir diese Datei dann zum Generieren der Datenbank.

Bei Updates fügen wir die Updates fest in die Software ein.Wir halten es fest codiert, weil wir Probleme nicht gerne lösen, bevor es wirklich ein Problem ist, und so etwas hat sich bisher noch nicht als Problem erwiesen.

In unserer Software haben wir also so etwas:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Dieser Code prüft, ob sich die Datenbank in Version 1 befindet (die in einer automatisch erstellten Tabelle gespeichert wird). Wenn sie veraltet ist, wird der Befehl ausgeführt.

Um die metadata.sql im Repository zu aktualisieren, führen wir diese Upgrades lokal aus und extrahieren dann die vollständigen Datenbankmetadaten.

Das Einzige, was hin und wieder passiert, ist, das Festschreiben der metadata.sql zu vergessen, aber das stellt kein großes Problem dar, da es im Build-Prozess einfach zu testen ist und das Einzige, was passieren kann, eine Neuinstallation mit ist eine veraltete Datenbank und aktualisierte diese bei der ersten Verwendung.

Wir unterstützen auch keine Downgrades, aber das ist so beabsichtigt. Wenn bei einem Update etwas kaputt geht, stellen wir die vorherige Version wieder her und reparieren das Update, bevor wir es erneut versuchen.

Ich erstelle Ordner, die nach den Build-Versionen benannt sind, und füge dort Upgrade- und Downgrade-Skripte ein.Beispielsweise könnten Sie die folgenden Ordner haben:1.0.0, 1.0.1 und 1.0.2.Jedes enthält das Skript, mit dem Sie Ihre Datenbank zwischen Versionen aktualisieren oder downgraden können.

Sollte ein Kunde oder Kunde Sie wegen eines Problems mit Version 1.0.1 anrufen und Sie verwenden 1.0.2, ist die Wiederherstellung der Datenbank auf seine Version kein Problem.

Erstellen Sie in Ihrer Datenbank eine Tabelle mit dem Namen „Schema“, in die Sie die aktuelle Version der Datenbank einfügen.Dann ist es ganz einfach, ein Programm zu schreiben, das Ihre Datenbank für Sie upgraden oder downgraden kann.

Genau wie Joey sagte: Wenn Sie sich in einer Rails-Welt befinden, verwenden Sie Migrations.:) :)

Für mein aktuelles PHP-Projekt verwenden wir die Idee der Rails-Migrationen und haben ein Migrationsverzeichnis, in dem wir den Dateititel „migration_XX.sql“ speichern, wobei XX die Nummer der Migration ist.Derzeit werden diese Dateien bei Aktualisierungen manuell erstellt, ihre Erstellung kann jedoch leicht geändert werden.

Dann haben wir ein Skript namens „Migration_watcher“, das, da wir uns in der Pre-Alpha-Phase befinden, derzeit bei jedem Seitenaufruf ausgeführt wird und prüft, ob es eine neue migration_XX.sql-Datei gibt, in der XX größer als die aktuelle Migrationsversion ist.Wenn ja, werden alle migration_XX.sql-Dateien bis zur größten Anzahl in der Datenbank ausgeführt und voilà!Schemaänderungen werden automatisiert.

Wenn Sie die Möglichkeit benötigen, das System zurückzusetzen, sind viele Anpassungen erforderlich, aber es ist einfach und hat bisher für unser relativ kleines Team sehr gut funktioniert.

Ich würde die Verwendung von Ant (plattformübergreifend) für die „Scripting“-Seite (da es praktisch mit jeder Datenbank da draußen über JDBC kommunizieren kann) und Subversion für das Quell-Repository empfehlen.Mit Ant können Sie Ihre Datenbank in lokalen Dateien „sichern“, bevor Sie Änderungen vornehmen.1.Sicherung vorhandener DB -Schema, um über Ant 2 zu versehen.Versionskontrolle für Subversion Repository über Ant 3.Senden Sie neue SQL-Anweisungen über Ant an die Datenbank

Toad für MySQL verfügt über eine Funktion namens Schema Compare, mit der Sie zwei Datenbanken synchronisieren können.Es ist das beste Werkzeug, das ich bisher verwendet habe.

Meiner Meinung nach haben Migrationen ein großes Problem:

Das Upgrade von einer Version auf eine andere funktioniert einwandfrei, aber die Neuinstallation einer bestimmten Version kann ewig dauern, wenn Sie Hunderte von Tabellen und eine lange Änderungshistorie haben (wie wir).

Das Ausführen des gesamten Delta-Verlaufs von der Baseline bis zur aktuellen Version (für Hunderte von Kundendatenbanken) kann sehr lange dauern.

Mir gefällt die Art und Weise, wie Yii kümmert sich um Datenbankmigrationen.Bei einer Migration handelt es sich grundsätzlich um die Implementierung eines PHP-Skripts CDbMigration. CDbMigration definiert eine up Methode, die die Migrationslogik enthält.Es ist auch möglich, a down Methode zur Unterstützung der Umkehrung der Migration.Alternative, safeUp oder safeDown kann verwendet werden, um sicherzustellen, dass die Migration im Kontext einer Transaktion erfolgt.

Yiis Befehlszeilentool yiic Enthält Unterstützung zum Erstellen und Ausführen von Migrationen.Migrationen können einzeln oder stapelweise angewendet oder rückgängig gemacht werden.Das Erstellen einer Migration führt zu Code für die Implementierung einer PHP-Klasse CDbMigration, eindeutig benannt basierend auf einem Zeitstempel und einem vom Benutzer angegebenen Migrationsnamen.Alle Migrationen, die zuvor auf die Datenbank angewendet wurden, werden in einer Migrationstabelle gespeichert.

Weitere Informationen finden Sie unter Datenbankmigration Artikel aus dem Handbuch.

Probieren Sie db-deploy aus – hauptsächlich ein Java-Tool, funktioniert aber auch mit PHP.

Es gibt eine Befehlszeile mysql-diff Tool, das Datenbankschemata vergleicht, wobei das Schema eine Live-Datenbank oder ein SQL-Skript auf der Festplatte sein kann.Es eignet sich für die meisten Schemamigrationsaufgaben.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow