prisma db push statt Migrationen — bewusst

Es gibt zwei Wege, ein Datenbankschema über die Zeit weiterzuentwickeln. Der eine erzeugt für jede Änderung eine Migrationsdatei, die versioniert und nacheinander ausgeführt wird. Der andere gleicht die Datenbank direkt an das Schema an.

Der erste gilt als der richtige. Ich benutze seit einem Jahr überwiegend den zweiten und finde die Diskussion darüber lehrreicher als die Entscheidung selbst.

Was Migrationen leisten

Nachvollziehbarkeit. Jede Änderung ist eine Datei mit Datum. Man sieht, wann welche Spalte dazukam.

Wiederholbarkeit. Dieselbe Reihenfolge führt überall zum selben Ergebnis.

Datenumzüge. Der Punkt, den ich für den wichtigsten halte: Wenn eine Spalte aufgeteilt wird, müssen die vorhandenen Daten umgeschrieben werden. Das kann nur eine Migration, kein automatischer Abgleich.

Rückwärtsschritte. Zumindest theoretisch.

Warum ich trotzdem anders arbeite

Meine Situation hat drei Eigenschaften, die die Rechnung verändern.

Ich bin die einzige Person, die Schemaänderungen macht. Der Hauptnutzen von Migrationen ist Koordination in einem Team. Es gibt niemanden, mit dem ich mich koordinieren muss.

Es gibt genau eine produktive Datenbank. Kein Dutzend Kundeninstallationen, bei denen jede auf einem anderen Stand ist.

Die allermeisten Änderungen sind additiv. Neue Tabelle, neue Spalte mit Standardwert, neuer Index. Solche Änderungen sind risikoarm.

Für diesen Zuschnitt ist der direkte Abgleich schlicht schneller: Schema ändern, ein Befehl, fertig. Kein Wachsen einer Migrationshistorie, die niemand liest.

Die Regeln, die ich mir dafür gesetzt habe

Weil der direkte Abgleich weniger Sicherheitsnetz hat, gelten bei mir vier Regeln — und die sind der eigentliche Inhalt dieses Eintrags.

Regel 1: Nie ohne Sicherung. Vor jedem Abgleich auf der produktiven Datenbank eine Kopie. Bei einer Datei-basierten Datenbank ist das ein Befehl und dauert Sekunden.

Regel 2: Erst anzeigen lassen, dann ausführen. Das Werkzeug kann vorher zeigen, welche Anweisungen es ausführen würde. Ich lese das jedes Mal. Wenn dort ein DROP steht, das ich nicht erwartet habe, breche ich ab.

Regel 3: Umbenennungen sind Handarbeit. Ein automatischer Abgleich erkennt keine Umbenennung — er sieht eine gelöschte und eine neue Spalte, und dann sind die Daten weg. Umbenennungen mache ich deshalb ausdrücklich in zwei Schritten: neue Spalte anlegen, Daten kopieren, Code umstellen, alte Spalte später entfernen.

Regel 4: Datenumzüge sind eigene Skripte. Wenn eine Änderung nicht nur die Struktur, sondern auch den Inhalt betrifft, schreibe ich ein Skript, das ich versioniere — im Grunde eine Migration, nur ausdrücklich als solche und nur dort, wo sie wirklich nötig ist.

Warnung

Regel 3 ist die, bei der Leute Daten verlieren. Der Abgleich ist bei additiven Änderungen harmlos und wird genau dann gefährlich, wenn etwas verschwindet. Wer den Vorschlag nicht liest, bevor er bestätigt, arbeitet ohne Netz — und das Werkzeug warnt zwar, aber die Warnung sieht bei der zwanzigsten harmlosen Änderung genauso aus wie bei der einen gefährlichen.

Was ich dadurch verloren habe

Ehrlichkeit gehört dazu.

Die Historie fehlt. Ich kann nicht nachvollziehen, wann eine Spalte dazukam, außer über die Versionsverwaltung der Schemadatei — was funktioniert, aber unbequemer ist.

Ein zweiter Aufbau ist nicht identisch. Wenn ich das System woanders neu aufsetze, entsteht das Schema aus der aktuellen Datei. Das ist meistens dasselbe Ergebnis, aber nicht garantiert dasselbe wie eine schrittweise Migration.

Der Weg zurück fehlt. Es gibt nichts, was eine Änderung rückgängig macht. Der Rückweg ist die Sicherung.

Der Ablauf, den ich für jede Schemaänderung benutze

Damit der direkte Abgleich sicher bleibt, gibt es bei mir eine feste Reihenfolge. Sie ist kurz genug, dass ich sie tatsächlich einhalte.

Sicherung ziehen. Bei einer Datei-Datenbank ein Befehl, wenige Sekunden.
Änderung im Schema. Nur eine Sache pro Durchlauf.
Vorschau anzeigen lassen. Welche Anweisungen würden laufen?
Die Vorschau lesen. Steht dort etwas Zerstörerisches, das ich nicht erwartet habe — abbrechen.
Ausführen.
Gegenprüfen, dass Daten unverändert sind. Zeilenzahlen der betroffenen Tabellen.

Schritt 4 ist der einzige, der wirklich zählt, und er ist der, den man nach dem zwanzigsten Mal überspringt. Deshalb ist Schritt 1 davor — als Auffangnetz für den Tag, an dem ich es tue.

Was passiert, wenn man die Regeln bricht

Ein Beispiel aus der Praxis, weil abstrakte Warnungen selten überzeugen.

Ich wollte ein Feld umbenennen. Der Abgleich hätte das als „Feld A entfernen, Feld B anlegen" ausgeführt — mit dem Ergebnis, dass alle Werte weg gewesen wären.

Die Vorschau hat es gezeigt, ich habe abgebrochen, und die Umbenennung lief stattdessen in vier Schritten: neues Feld anlegen, Daten kopieren, Code umstellen, altes Feld später entfernen. Vier Schritte über zwei Tage statt einem Befehl.

Das ist der Preis dieses Vorgehens. Bei additiven Änderungen — und das sind bei mir gut neunzig Prozent — ist es schneller als jede Migration. Bei den restlichen zehn Prozent ist es aufwendiger, und man muss die Disziplin haben, den Unterschied zu erkennen.

Wer diese Disziplin nicht hat oder nicht haben kann — weil mehrere Leute am Schema arbeiten —, ist mit Migrationsdateien besser bedient. Das ist keine Frage der Fähigkeit, sondern der Umstände.

Wann ich wechseln würde

Ich halte meine Entscheidung für richtig — für meine Situation. Sie kippt in dem Moment, in dem einer dieser drei Punkte eintritt:

Eine zweite Person macht Schemaänderungen.
Es gibt mehr als eine produktive Installation. Sobald jemand anderes das System betreibt, brauchen die Aktualisierungen einen definierten Ablauf.
Änderungen werden regelmäßig zerstörerisch. Wenn Umbauten die Regel statt die Ausnahme sind, ist der Vorschlagsmodus zu wenig.

Ich schreibe das hier auf, damit ich beim nächsten Grundsatzgespräch mit mir selbst nicht bei null anfange. Und weil ich glaube, dass „Migrationen sind der professionelle Weg" ein Satz ist, den man begründen können sollte, bevor man ihn übernimmt.