Tool-gestütztes Datenbank-Refactoring

Eher selten werden damit Umstrukturierungen einer relationalen Datenbank in Verbindung gebracht. Dabei ist eine Datenbank ein wichtiger Bestandteil einer entwickelten Anwendung. Und die Datenbankstruktur verändert sich im Lebenszyklus eines Softwareprojekts fast genauso häufig wie der Sourcecode und sollte entsprechend mit derselben Sorgfalt behandelt werden. Deshalb möchte ich euch im Folgenden ein paar nützliche Tipps an die Hand geben.

Datenbank-Refactoring zweiter Klasse

Wenn eine Änderung am Sourcecode auch eine Änderung an der Datenbankstruktur mit sich zieht, solltet ihr ein SQL-Skript erstellen, das die Änderung durchführt − beispielsweise das Hinzufügen / Entfernen einer Tabelle beziehungsweise Tabellenspalte oder die Änderung eines Datentyps. Dieses Skript legt ihr im besten Fall neben dem Sourcecode in der Versionsverwaltung ab. Installiert ihr ein neues Release der Software auf einem Zielsystem, solltet ihr nun daran denken, alle Skripte, die sich seit dem letzten Release angehäuft haben, in der richtigen Reihenfolge auf der Zieldatenbank auszuführen. Häufig ist das ein manueller Schritt, den ihr in den Release Notes beschreiben müsst. Durch Fehler in der Dokumentation oder in der Durchführung entsteht somit ein gewisses Risiko. Während der Sourcecode der Anwendung die vollste Aufmerksamkeit genießt, fristen die SQL-Skripte meist ein Schattendasein und werden als Patienten zweiter Klasse behandelt. Schließlich wollt ihr ja auch Software entwickeln und nicht Datenbanken aktualisieren, richtig?

Datenbank-Refactoring done right

Ja, ihr wollt Software entwickeln! Aber warum macht ihr euch das Leben dann nicht einfach, indem ihr das Datenbank-Refactoring tool-gestützt automatisiert? Alles, was automatisiert ablaufen kann, verhindert nämlich manuelle Fehler und spart Zeit, die ihr viel besser für die Umsetzung von neuen Features nutzen könnt. Aber wie sieht so ein automatisiertes Datenbank-Refactoring aus?

Zunächst müsst ihr Änderungen an der Datenbankstruktur sammeln. Abhängig vom Tool, das ihr für das Datenbank-Refactoring verwendet, werden diese Änderungen in Form von SQL-Skripten oder anderen Sprachen wie XML, JSON oder YAML beschrieben. Diese Skripte werden − wie im naiven Ansatz auch − durchnummeriert und in der Versionsverwaltung abgelegt.

Der Vorteil, im Vergleich zur naiven Vorgehensweise, ist der Einsatz eines Tools, das die Ausführung der Skripte auf einer Datenbank für euch übernimmt. Steht ihr also vor der Aufgabe, eine Zieldatenbank auf den aktuellen Stand zu bringen, müsst ihr nur noch einen einzigen Befehl ausführen und alle Skripte werden nacheinander in die Datenbank eingespielt. Das Tool merkt sich, welche Skripte bereits durchgeführt wurden, sodass nur noch diejenigen Skripte durchgeführt werden, die noch fehlen. Dafür legt das Tool üblicherweise eine eigene Datenbanktabelle in der Zieldatenbank an. In dieser wird dokumentiert, welche Skripte bereits ausgeführt wurden.

Ein zusätzliches Feature solcher Datenbank-Refactoring-Tools ist die Prüfung, ob die Skripte, die bereits ausgeführt wurden, sich zwischenzeitlich verändert haben. Wenn ein Skript beispielsweise eine Spalte mit dem Namen “foo” anlegt, diese auf der Datenbank bereits angewandt wurde und das Skript erneut angepasst wird – zum Beispiel, wenn die Spalte etwa “bar” heißen soll − bricht das Tool bei der erneuten Anwendung auf derselben Datenbank den Vorgang ab. Hintergrund ist folgender: Es könnte schließlich sein, dass die Spalte “foo” auf einer anderen Zieldatenbank bereits angelegt wurde und dort würde dann zusätzlich noch eine zweite Spalte “bar” angelegt werden. Damit verhindert das Tool automatisch, dass fälschlicherweise beide Spalten vorhanden sind. Um zu prüfen, ob sich ein Skript verändert hat, legen Datenbank-Refactoring-Tools üblicherweise den Hash-Wert des Skripts in der Tabelle ab, in der auch die Information, welche Skripte bereits ausgeführt wurden, abgelegt ist.

Tools

Ein Datenbank-Refactoring-Tool nimmt euch also Arbeit ab. Außerdem verhindert es Fehler, wenn es darum geht, ein neues Release auf einer Zielumgebung einzuspielen.

Zwei beliebte Tools dieser Art sind „Liquibase“ und „Flyway“. Beide sind in Java entwickelt und brauchen zur Ausführung eine Java-Laufzeitumgebung. Der Vorteil ist: Ihr benötigt lediglich minimale Java-Kenntnisse, um sie zu nutzen. Daher sind diese beiden Tools keineswegs nur auf Java-Projekte beschränkt.

Im zweiten Teil meiner Blog-Serie werde ich die Vor- und Nachteile von „Liquibase“ und „Flyway“ noch ausführlicher beschreiben. Seid gespannt!

Habt ihr auch bereits Erfahrungen mit dem tool-gestützten Datenbank-Refactoring gemacht? Ich freue mich auf eure Kommentare.