Print-Version Jetzt Buch bestellen
10.7 Datenbankschema und Migrations 
Migrationen
Migrationen sind eine der nützlichsten Funktionen von Rails, wenn es um die Erstellung und Änderung des Datenbankschemas (Das Datenbankschema legt die in der Datenbank enthaltenen Tabellen fest. In relationalen Datenbanksystemen, wie Oracle, PostgreSQL, MySQL usw., wird das Datenbankschema mittels SQL definiert) geht.
Beispiel
Stellen Sie sich folgendes Szenario vor:
Sie haben eine Webapplikation erstellt (z. B. eine Weblog-Applikation), die bereits von vielen Benutzern erfolgreich auf Ihrer Website eingesetzt wird. Wenn Sie nun die Applikation korrigieren bzw. verbessern, kommt es häufig nicht nur zu Änderungen am Quelltext, sondern auch zu Änderungen am Datenbankschema.
Änderungen am Datenbankschema
Es ist ein Trugschluss zu glauben, man könne das Datenbankschema in der Planungsphase exakt festlegen. Während der Entwicklung einer Applikation durchläuft das Datenbankschema eine Evolution. Am Anfang werden Tabellen erstellt. Später wird das Datenbankschema durch neue Tabellenfelder und sogar durch neue Tabellen ergänzt. Es kann auch vorkommen, dass der Datentyp eines Feldes verändert wird oder ganze Tabellen wieder entfernt werden.
SVN oder CVS
Wenn Sie nun eine neue Version Ihrer Applikation mit den Änderungen veröffentlichen, stellt sich die Frage, wie die anderen Entwickler oder Benutzer die alte Version auf den neuesten Stand bringen. In der Regel stellt es kein Problem dar, den alten Quelltext einfach durch den neuen Quelltext zu ersetzten (z. B. mit Hilfe eines Versionierungs-Tools, wie Subversion oder CVS). Der springende Punkt liegt in der Aktualisierung des Datenbankschemas.
Das gleiche Problem ergibt sich auch, wenn Sie eine lokale Datenbank für die Entwicklung sowie eine Datenbank für den Produktionsserver verwenden. Auch hier müssen die Änderungen an der Entwicklungs-Datenbank auf dem Produktionsserver übernommen werden.
Wir können nicht einfach die Datenbank ersetzen, da dabei die Daten, die gegebenenfalls in jeder Datenbank unterschiedlich sind, verloren gehen.
Migration mit SQL
Die einfachste Lösung besteht darin, SQL-Code (Zum Ändern des Datenbankschemas gibt es bestimmte SQL-Befehle, wie z. B. CREATE TABLE und ALTER TABLE . Diese Befehle werden als Data Definition Language, kurz DDL, zusammengefasst) zu verwenden, der die Änderungen beschreibt. Das Problem an SQL besteht darin, dass sich trotz Standards die SQL-Befehle bei unterschiedlichen Datenbanksystemen im Detail unterscheiden. Da wir den anderen Entwicklern nicht diktieren möchten, welches Datenbanksystem sie zu verwenden haben, müssen wir einen Weg finden, datenbankunabhängig die Änderungen zu beschreiben.
Migration-Skripte
Hierfür bietet Rails mit der Klasse ActiveRecord::Migration eine sehr praktische Lösung. Für jede Änderung am Datenbankschema wird ein sogenanntes Migration-Skript angelegt. Innerhalb dieser Skripte werden die Änderungen am Datenbankschema in Ruby beschrieben. Diese Ruby-Befehle werden dann von Rails automatisch in SQL-Befehle für die in der Konfigurationsdatei eingestellte Datenbank umgesetzt. Das heißt, die Ruby-Befehle, die die Änderungen am Datenbankschema beschreiben, sind in der Regel unabhängig vom Datenbanksystem. Diese Migration-Skripte müssen bei jedem Update der Applikation ausgeführt werden, damit die Änderungen auf die Datenbank angewendet werden können.
| Keine Datenbanksystemunabhängigkeit um jeden Preis |
| Migration bietet zwar die Möglichkeit der Datenbanksystemunabhängigkeit, der Preis dafür ist aber, dass besondere Fähigkeiten eines bestimmten Datenbanksystems nicht genutzt werden. Wenn Sie z. B. eine Rails-Applikation für einen bestimmten Kunden erstellen, der bereits das Datenbanksystem festgelegt hat, so ist Datenbanksystemunabhängigkeit nicht unbedingt notwendig. Wenn Sie jedoch eine Applikation für eine breite Massse (wie z. B. ein Weblogsystem) erstellen, so sollten Sie sich nicht auf ein Datenbanksystem fixieren, um den Nutzern die Wahlmöglichkeit zu überlassen. |
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.
