Ungefähr zur gleichen Zeit, als Git populär wurde, wurde auch der Trend bekannt, webbasierte Anwendungen mit objektrelationalen Mapping-Bibliotheken (ORM) zu schreiben. Die Schlüsselidee war folgende: Da Entwickler Änderungen am Code vornehmen können, die mit Git leicht rückgängig gemacht werden können, warum können Entwickler nicht dasselbe tun, wenn es um Schemaänderungen geht? Schließlich beinhaltet jede vernünftige neue Funktion Code- und Schemaänderungen. So beliebte Frameworks wie Rails und Django hinzugefügt ORM und Datenbankmigration (auch als Schema-Migration bekannt) als Teil ihres Angebots. Die Datenbankmigration als Konzept ist jedoch nicht auf gängige Webframeworks beschränkt. Es gibt sogar eigenständige Datenbankmigrationssoftwarebibliotheken wie Flyway und Liquibase. Können Sie sich vorstellen, beim Schreiben Ihres Codes granulare Änderungen am Schema rückgängig machen zu können? Zu oft finde ich, dass Artikel über Datenbankmigration nicht diskutieren, was es bedeutet, als Entwickler aktiv zu sein. Ich möchte das hier korrigieren. In diesem Sinne gebe ich Ihnen heute einen Überblick darüber, was die Datenbankmigration beinhaltet und wie Sie in einer aktiven Entwicklungsumgebung vorgehen. Ich werde dies in drei Abschnitte unterteilen, in denen beschrieben wird, was während des Migrationsprozesses passiert, welche gängigen Tools verwendet werden und welche Fallstricke bei der Datenbankmigration auftreten können. Dies sollte einem Anfänger-Entwickler die Werkzeuge geben, um schnell die wichtigsten Ideen hinter der Datenmigration zu lernen und auch mögliche Fallstricke zu vermeiden, wenn er die Datenbankmigration als Teil seiner Entwicklungs-Toolbox verwendet.
Was passiert bei der Datenbankmigration?
Nun, da Sie wissen, wie Datenbankmigrationen zustande kamen, lassen Sie mich Sie durch das führen, was sie tatsächlich mit sich bringen.
Granulare Änderungen werden als einzelne Skriptdateien generiert
Ich habe erwähnt, wie Datenbankmigrationen im Grunde genommen granulare Änderungen an Ihrem Datenbankschema (und manchmal auch an Ihren Daten) verfolgen. Diese granularen Änderungen werden in der Regel als separate Skriptdateien wiedergegeben. Auf diese Weise werden Ihre granularen Schemaänderungen als Code wiedergegeben, der mit jeder Versionskontrollsoftware erfasst werden kann. Dies ist ein Beispiel für eine Migrationsdatei in Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
Sie können Migrationen nicht nur als eigenständige Dateien haben, sondern auch das aktuelle Datenbankschema als eigene Datei. In der Regel wird dies als Schemadatei bezeichnet.
Datenbankmigrationsskripte sind werkzeugabhängig
Rufen Sie das Datenbankmigrationsskript in Ruby aus unserem früheren Beispiel auf. Hier ist eine weitere Datenbankmigrationsdatei aus der unabhängigen Quellcodeverwaltung für die Datenbanksoftware Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
Dieses Mal ist die Datei im XML-Format. Tatsächlich kann Liquibase Migrationsänderungen (oder Changesets, wie sie gerne genannt werden) in mehreren Formaten wie XML und JSON erstellen. Wenn Sie also Ihre Datenbankmigration nicht von Hand im SQL-Format schreiben möchten, gibt es keine wirklichen Standards für die Erstellung der Migrationsdateien. Natürlich können Sie Ihre eigenen benutzerdefinierten Datenbankmigrationsskripte in die SQL-Dateien schreiben. Aber warum handschreiben und versehentlich Fehler einführen, wenn Sie Tools zum automatischen Generieren der Datenbankmigrationen verwenden können?
Wie führen Sie eine Datenbankmigration durch?
Jetzt wissen Sie, was eine Datenbankmigration ist. Sie müssen auch (zumindest konzeptionell) wissen, wie eine Datenbankmigration durchgeführt wird. Leider gibt es überhaupt keine Standards für Datenbankmigrationsdateien, was bedeutet, dass wir nicht zu sehr ins Detail gehen können, wie sie erstellt werden. Mit anderen Worten, wie Sie eine Datenbankmigration durchführen, hängt stark von dem spezifischen Tool ab, das Sie für die Aufgabe verwenden. In diesem Abschnitt werden die beiden häufigsten Methoden zur Durchführung einer Datenbankmigration behandelt.
Option 1: Verwenden Sie eine Framework- / sprachabhängige Bibliothek
Wenn Sie eine gängige Sprache verwenden (Ruby, PHP, Python usw.) oder Framework (Rails, Django, etc.), dann gibt es gut dokumentierte Bibliotheken für die Datenmigration innerhalb des Universums des gewählten Frameworks / der gewählten Sprache. Die beliebten Web-Frameworks werden natürlich mit den Datenbankmigrationsfunktionen gebündelt. Je nach Konfiguration können Sie die native Datenbankmigration sogar gegen andere Bibliotheken in der gewählten Sprache austauschen. In diesem Szenario generieren Sie die Migrationsdateien normalerweise über die Befehlszeile. Gelegentlich müssen Sie den benutzerdefinierten Code möglicherweise für einige Änderungen, z. B. die Datenmigration oder sogar das Rückgängig Machen der Änderung selbst, von Hand schreiben. Ansonsten erledigt die im Framework / in der Sprache ausgewählte Bibliothek dies für Sie.
Option 2: Verwenden Sie unabhängige Software für die Datenbankmigration
In einigen Fällen möchten Sie Software wie Flyway oder Liquibase verwenden, die nur als Quellcodeverwaltung für Ihre Datenbank dient. Auf diese Weise vermeiden Sie, an ein bestimmtes Framework oder eine bestimmte Sprache gebunden zu sein. Dies bedeutet nicht, dass Sie null Lock-in haben. Nehmen wir zum Beispiel Flyway, das gut mit verschiedenen Datenbanken wie Oracle, MySQL und MariaDB funktioniert. Wenn Sie die Java-basierte Migration von Flyway nicht verwenden (wodurch Sie in Java und Flyway gesperrt werden), verwenden Sie möglicherweise die SQL-basierte Migration (wodurch Sie an die Datenbank und Flyway Ihrer Wahl gebunden sind). Die gute Nachricht ist, Flyway und Liquibase sind beide relativ einfach zu bedienen. Auch sie bieten eine Befehlszeilenmethode zum Generieren der Migrationen und ermöglichen die benutzerdefinierte Codierung zum Erfassen der Datenbankschemamigrationen.
Auswahl der besten Option für Sie
Hier ist meine Meinung zur Wahl zwischen beiden Optionen. Ich neige dazu zu sehen, dass die meisten Entwickler Option 1 wählen. Normalerweise liegt das daran, dass Entwickler bereits eine bevorzugte Sprache / ein bevorzugtes Framework haben, so dass es sich kognitiv nicht so anfühlt, als würden sie (noch) eine andere Software lernen. Und die Bindung (im Fall von Option 1 wäre dies an das Framework und die Sprache) ist völlig freiwillig und erwünscht. Sie können sich für Option 2 entscheiden, wenn sich Ihr Team nicht vollständig für eine bestimmte Sprache oder ein bestimmtes Framework entschieden hat. Für was auch immer Sie sich entscheiden, vermeiden Sie es, Ihre Wahl in der Mitte der Entwicklung unnötig zu ändern. Die Datenbankmigration ist kein Bereich, in dem das Ändern der Tools enorme Vorteile bringt. Die meisten Vorteile ergeben sich aus der einfachen Einrichtung der Datenbankmigration.
Die Gefahren der Datenbankmigration und wie man sie vermeidet
Im vorherigen Abschnitt habe ich die beiden wichtigsten Arten von Tools für die Datenbankmigration behandelt: framework- / sprachabhängige und eigenständige Software. Beide Typen sind einfach zu bedienen. Jetzt werde ich drei Best Practices empfehlen, wenn es darum geht, eine Datenbankmigration tatsächlich durchzuführen. Diese Tipps adressieren die Hauptgefahr der Datenbankmigration: Sie möchten irreversible Änderungen vermeiden.
Wählen Sie ein Datenbankmigrationstool und bleiben Sie dabei
Ich habe dies bereits kurz erwähnt, aber es lohnt sich zu betonen: Ich möchte davor warnen, unnötige Änderungen am Toolset vorzunehmen, nur weil es cool ist. Denken Sie daran, dass Datenbankmigrationsskripte von dem Tool abhängen, mit dem Sie sie generieren. Es gibt keine richtigen Standards für diese Skripte. Wenn Sie wirklich wollen, können Sie sogar Ihre eigenen in SQL-Anweisungen schreiben. Das führt zu eigenen Problemen; Zum Beispiel können Ihre SQL-Skripte wahrscheinlich datenbankabhängig sein. MySQL-Abfragen funktionieren möglicherweise nicht in PostgreSQL und umgekehrt. Sie sind also entweder an Ihr Datenbankmigrationstool gebunden oder an die Datenbank Ihrer Wahl — oder in einigen Fällen sogar an beides. Es gibt keine offensichtlichen Vorteile, wenn Sie Ihr Toolset häufig wechseln, daher empfehle ich, ein Datenbankmigrationstool auszuwählen und dabei zu bleiben. Es gibt bessere Dinge mit Ihrer Zeit zu tun, als Ihre Räder unnötig zu drehen.
Löschen Sie Zeilen oder Spalten nur, wenn Sie absolut sicher sind, dass Sie dies benötigen
Wenn es um Migrationen geht, können Sie diese bei Bedarf größtenteils rückgängig machen. Typische Datenbankmigrationstools können einfache reversible Änderungen verarbeiten. Und selbst wenn dies nicht möglich ist, können Sie ganz einfach Ihren eigenen benutzerdefinierten Code hinzufügen, um beim Umkehren zu helfen. In Rails fügen Sie beispielsweise einfach den Code unter reversible hinzu.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
Die schwierigsten Änderungen, die rückgängig gemacht werden müssen, beinhalten das Löschen von Daten: insbesondere das Löschen von Spalten oder Datenzeilen. Wenn Ihre Datenbank viele Daten enthält, müssen Sie möglicherweise eine erhebliche Menge an benutzerdefiniertem Code schreiben, um Ihre Änderungen rückgängig zu machen. Wenn Sie also erwägen, Daten aus Ihrer Datenbank zu löschen, seien Sie besonders vorsichtig. Solche Änderungen sind schwer rückgängig zu machen. Andere schwer rückgängig zu machende Änderungen umfassen das Umbenennen von Spalten und das Ändern des Datentyps einer Spalte, die bereits Daten enthält. Eine Faustregel, die ich gerne anwende, lautet: Sie sollten Spalten fast nie bis zum nächsten Major löschen (Sie kennen Semver, oder?) veröffentlichen. Diese Regel gilt auch, wenn ich Spalten habe, die ich nicht mehr verwenden möchte. Anstatt Spalten zu löschen, werde ich in den Nebenversionen bekannt geben, welche Spalten in Zukunft veraltet sind. Wenn es Zeit für eine Hauptversion ist, werde ich diese Spalten vollständig löschen. Auf diese Weise reduziere ich die Wahrscheinlichkeit einer versehentlichen, unerwünschten Änderung, die von Hand rückgängig gemacht werden muss.
Implementieren von Feature-Flags
Eine weitere hervorragende Strategie für die Datenbankmigration ist die Implementierung von Feature-Flags, insbesondere wenn Sie ein großes Team haben und mehrere Personen versuchen, verschiedene Funktionen für dieselbe Codebasis zu implementieren. Laut Martin Fowler sind Feature-Flags „eine leistungsstarke Technik, mit der Teams das Systemverhalten ändern können, ohne den Code zu ändern.“ Je größer Ihr Team und je komplexer Ihre Codebasis ist, desto mehr Feature-Flags leuchten. Feature-Flags helfen, Risiken bei Datenbankmigrationen zu minimieren. Der Versuch, die Änderungen zu entwirren, wenn Sie bestimmte Funktionen zurücksetzen müssen, kann ein echter Albtraum sein. Feature-Flags funktionieren genauso gut, unabhängig davon, ob Sie kleine oder große Änderungen am Datenbankschema vornehmen möchten. Wenn Sie Feature-Flags verwenden, empfehle ich Ihnen, insgesamt häufigere und detailliertere Änderungen vorzunehmen. Und Sie können wirklich sehen, wie Feature-Flags Ihren Entwicklungsprozess unterstützen, wenn Sie eine massive Schemaänderung durchführen. Bitte versuchen Sie immer noch, diese massive Schemaänderung in kleinere, dünne Scheiben zu zerlegen. Sie müssen niemanden damit beeindrucken, wie viel Sie in einer Änderung ausdrücken können. Fügen Sie Ihren Entwicklungspraktiken besser Schutzmaßnahmen hinzu, indem Sie alle drei Empfehlungen implementieren, über die ich in diesem Abschnitt gesprochen habe.
Fazit
Entwickler brauchen alle Werkzeuge, die sie bekommen können, um ihr Leben einfacher zu machen. Die Datenbankmigration ist eines dieser unverzichtbaren Tools für die Toolbox des Entwicklers. In Zukunft sehe ich voraus, dass sich der Einsatz von Datenbankmigrationen von einer Best Practice für die Entwicklung zu einer Entwicklungsstandardpraxis entwickeln wird. Die Leute werden Sie lustig ansehen, weil Sie die Datenbankmigration überhaupt nicht verwenden. Dennoch ist es wichtig zu bedenken, wie Datenbankmigrationen bei Ihnen nach hinten losgehen können, insbesondere bei schwer rückgängig zu machenden Schemaänderungen. Seien Sie sich dieser Änderungen absolut sicher, bevor Sie sie live schalten. Wenn Sie die Datenbankmigration noch nicht in Ihrem Prozess verwenden, worauf warten Sie? Es ist einfach zu starten, und Sie können es sogar in der Mitte Ihres Entwicklungszyklus hinzufügen. Du wirst dankbar sein, dass du es getan hast. Denn wenn der Tag kommt, an dem Sie Ihre Änderungen rückgängig machen müssen und die Änderungen die Datenbank betreffen, wünschen Sie sich, Sie hätten etwas, das Ihnen dabei hilft, dies in nur wenigen Sekunden zu tun. Datenbankmigration ist das, was Sie sich wünschen würden.