Fast jede größere Software, mindestens serverseitige Software, benutzt Datenbanken. Früher war dies „immer“ Oracle, außer man war in einer sehr Mainframe-lastigen Umgebung, dann war es halt DB2, oder in einer sehr Microsoft-lastigen Umgebung, dann war es MS-SQL-Server.
Das scheint sich jetzt ein bißchen zu ändern. Oracle scheint viele Kunden mit seiner Lizenzpolitik verärgert zu haben und andererseits sind die Alternativen PostgreSQL und verschiedene mySQL-Derivate (z.B. MariaDB) inzwischen auf einem guten Stand, der es erlaubt, viele Aufgaben, für die man früher selbstverständlich auf Oracle-Datenbanken gesetzt hat, damit zu lösen, auch für größere Datenbanken. Mir scheint es immer noch so zu sein, dass man mit mySQL oder MariaDB an Grenzen stößt, und für viele Zwecke PostgreSQL die bessere Wahl ist.
Andererseits kommen auch vermehrt die sogenannten NoSQL-Datenbanken auf, z.B. Riak, Neo4J, MongoDB, Redis und etliche mehr.
Mit der Weiterentwicklung der Software gehen irgendwann auch Änderungen des Datenmodells einher. In der klassischen Welt der SQL-Datenbanken führt man dann eine Migration durch, wo neue Tabellen hinzugefügt werden, vorhandene geändert werden und Daten transformiert werden. Theoretisch geht das zumindest bei kleineren Änderungen, ohne die Applikation abzuschalten, aber für größere Änderungen fährt man doch gerne sicherheitshalber die Applikation so lange herunter, wenn man die Möglichkeit hat, und sei es nur, damit die Migration schneller fertig wird. Idealerweise wird die Software dann natürlich im gleichen Atemzug auch umgestellt und wenn danach alles gut läuft, ist es gut. Wenn man es merkt, dass etwas nicht stimmt, bevor die neue Software Daten angelegt hat, kann man einfach das Backup einspielen und es in der nächsten Nacht noch einmal probieren. Schlimmer ist der Fall, wenn man es erst nach einer Weile merkt, dass die Applikation nicht mehr rund läuft und wenn man dann schon Daten verloren hat oder zumindest in einem Zustand hat, der es nur mit großer Mühe erlaubt, das zu korrigieren. Deshalb empfielt es sich, so eine Migration gut zu testen und zwar nicht nur mit leeren Datenbanken, sondern mit richtigen Daten. Sinnvoll sind anonymisierte Daten aus der Produktivdatenbank.
Ein völlig anderer Ansatz drängt sich bei schemalosen Datenbanken wie MongoDB auf. Man kann bei einer Änderung der Software einfach alle Daten so lassen, wie sie sind, vorausgesetzt, die Software ist in der Lage alte und neue Daten zu unterscheiden. Das kann sich am vorhandensein eines Attributs erkennen lassen, aber auch an einem Versionsattribut. Wenn nun ein Dokument, so heißen die „Datensätze“ in MongoDB, verwendet wird, kann die Software in diesem Moment die Migration mit geeigneten Defaultwerten oder berechneten Werten für neu hinzukommenden Felder für das eine Dokument durchführen. So kann die Migration unter Umständen Tage oder sogar Jahre dauern, aber die Applikation kann abgesehen von der Problematik des eigentlichen Software-Updates durchgängig laufen.
Grundsätzlich ließe sich dieser Ansatz auch für SQL-Datenbanken denken. Man kann zum Beispiel bei der Migration eine leere Tabelle anlegen, die die migrierten Daten einer vorhandenen Tabelle aufnehmen kann und die Daten so nach und nach durch die Applikation transformieren und in die neue Tabelle verschieben. In der Praxis wird das aber kompliziert, wenn man noch so Dinge wie referenzielle Integrität berücksichtigen will. So wird uns der bewährte klassische Ansatz für Datenbankmigrationen wohl noch lange erhalten bleiben.
