Migration von Datenbankschemata mit Liquibase

Datenbanken im Wandel

Christian Kaltepoth


Für fast alle nicht-trivialen Anwendungen ist die Persistierung von Daten ein zentrales Thema. Obwohl sich ein Trend in Richtung der NoSQL-Datenbanken abzeichnet, sind die klassischen relationalen Datenbanken für Geschäftsanwendungen weiterhin die erste Wahl.

Eine der wesentlichen Eigenschaften von relationalen Datenbanken ist, dass jede Datenbank über ein fest definiertes Schema verfügt. Dieses Schema legt sehr detailliert die Struktur der gespeicherten Daten und die Beziehungen zwischen den einzelnen Tabellen fest.

Das Schema einer Datenbank bleibt über den Lebenszyklus einer Anwendung oft nicht unverändert, sondern entwickelt sich mit der Anwendung weiter. Besonders bei der Implementierung neuer Funktionen kommt man häufig um eine Erweiterung des Datenmodells nicht herum. Sei es, weil neue Daten gespeichert werden müssen, oder weil sich aufgrund veränderter Anforderungen die Struktur der Daten ändert.

Muss das Datenbankschema angepasst werden, kommt es schnell zu den ersten Problemen. Wie sorgt man dafür, dass die Änderung auch wirklich auf allen Datenbanken korrekt durchgeführt wird? Zunächst einmal existieren häufig mehrere Datenbanken, die das Projektteam bei der täglichen Entwicklungsarbeit nutzt. Nicht selten hat sogar jeder Entwickler seine eigene Testdatenbank. Dazu kommen noch die Staging- und QA-Systeme. Geht das Update der Applikation dann irgendwann in die Produktion, haben sich seit dem letzten Release schon eine ganze Reihe von Änderungen summiert, die dann auf der Produktionsdatenbank durchgeführt werden müssen.

Während die Migration der Datenbankstruktur auf den Staging- und Produktivsystemen noch in geordneten Bahnen abläuft, sieht es in den Projektteams häufig anders aus. Wie oft wird man dort von Fehlermeldungen bezüglich fehlender Spalten überrascht, wenn das Schema der eigenen Testdatenbank mal wieder nicht auf dem aktuellsten Stand ist!

Die Lösung für dieses Problem ist eigentlich ganz einfach: Es wird ein System benötigt, das es erlaubt, alle Modifikationen des Schemas zu dokumentieren. Diese Information sollte – genau wie der Quellcode der Anwendung selbst – in einem Versionskontrollsystem verwaltet werden. Außerdem muss es einen automatisierten Weg geben, die bisher nicht durchgeführten Änderungen auf einer Datenbank anzuwenden.

Liquibase

Bei Liquibase [1] handelt es sich um ein Open-Source-Werkzeug zur Verwaltung von Strukturänderungen an relationalen Datenbanken. Dabei unterstützt Liquibase nicht nur dabei, die Modifikationen des ...

Migration von Datenbankschemata mit Liquibase

Datenbanken im Wandel

Christian Kaltepoth


Für fast alle nicht-trivialen Anwendungen ist die Persistierung von Daten ein zentrales Thema. Obwohl sich ein Trend in Richtung der NoSQL-Datenbanken abzeichnet, sind die klassischen relationalen Datenbanken für Geschäftsanwendungen weiterhin die erste Wahl.

Eine der wesentlichen Eigenschaften von relationalen Datenbanken ist, dass jede Datenbank über ein fest definiertes Schema verfügt. Dieses Schema legt sehr detailliert die Struktur der gespeicherten Daten und die Beziehungen zwischen den einzelnen Tabellen fest.

Das Schema einer Datenbank bleibt über den Lebenszyklus einer Anwendung oft nicht unverändert, sondern entwickelt sich mit der Anwendung weiter. Besonders bei der Implementierung neuer Funktionen kommt man häufig um eine Erweiterung des Datenmodells nicht herum. Sei es, weil neue Daten gespeichert werden müssen, oder weil sich aufgrund veränderter Anforderungen die Struktur der Daten ändert.

Muss das Datenbankschema angepasst werden, kommt es schnell zu den ersten Problemen. Wie sorgt man dafür, dass die Änderung auch wirklich auf allen Datenbanken korrekt durchgeführt wird? Zunächst einmal existieren häufig mehrere Datenbanken, die das Projektteam bei der täglichen Entwicklungsarbeit nutzt. Nicht selten hat sogar jeder Entwickler seine eigene Testdatenbank. Dazu kommen noch die Staging- und QA-Systeme. Geht das Update der Applikation dann irgendwann in die Produktion, haben sich seit dem letzten Release schon eine ganze Reihe von Änderungen summiert, die dann auf der Produktionsdatenbank durchgeführt werden müssen.

Während die Migration der Datenbankstruktur auf den Staging- und Produktivsystemen noch in geordneten Bahnen abläuft, sieht es in den Projektteams häufig anders aus. Wie oft wird man dort von Fehlermeldungen bezüglich fehlender Spalten überrascht, wenn das Schema der eigenen Testdatenbank mal wieder nicht auf dem aktuellsten Stand ist!

Die Lösung für dieses Problem ist eigentlich ganz einfach: Es wird ein System benötigt, das es erlaubt, alle Modifikationen des Schemas zu dokumentieren. Diese Information sollte – genau wie der Quellcode der Anwendung selbst – in einem Versionskontrollsystem verwaltet werden. Außerdem muss es einen automatisierten Weg geben, die bisher nicht durchgeführten Änderungen auf einer Datenbank anzuwenden.

Liquibase

Bei Liquibase [1] handelt es sich um ein Open-Source-Werkzeug zur Verwaltung von Strukturänderungen an relationalen Datenbanken. Dabei unterstützt Liquibase nicht nur dabei, die Modifikationen des ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang