Refactorings am Code verursachen entsprechende Refactorings an den Datenbankstrukturen. Besonders häufig findet man Umbenennungen von Spalten, Typänderungen von Spalten sowie das Löschen von Spalten.
Viele Datenbanken unterstützen das Umbenennen von Spalten direkt. Dort wo es nicht geht, fügt man eine neue Spalte mit dem Zielnamen ein, kopiert die Daten von der Quell- in die Zielspalte und löscht schließlich die Quellspalte. Mit ALTER TABLE und UPDATE ist das alles auch kein Problem. Bei Typänderungen von Spalten geht man genauso vor, nur dass man zwischendurch eine temporäre Spalte einführt (sonst bekommt man einen Namenskonflikt zwischen Quell- und Zielspalte).
Das Schreiben dieser Migrationsskripte scheint erstmal sehr aufwändig und unangenehm. In unseren Projekten haben wir allerdings festgestellt, dass es dann doch nicht so schlimm ist. Auf jeden Fall ziehen wir das Schreiben der Migrationsskripte dem Hinauszögern oder Weglassen von Releases vor.
Es gibt nur ein wiederkehrendes Problem und das heißt DB2: DB2 ist anscheinend die einzige Datenbank, die Tabellenspalten nicht löschen kann.
Wir behelfen uns in diesem Fall mit temporären Tabellen: Wir legen zuerst eine Kopie der Quelltabelle an und kopieren die Daten von der Quelltabelle in die temporäre Tabelle. Dann löschen wir die Quelltabelle und legen sie mit der Zielstruktur neu an. Dann migrieren wir die Daten von der temporären Tabelle in die neue Zieltabelle (mit INSERT) und löschen schließlich die Temporärtabelle. Das ist leider aufwändig und auch fehleranfällig, weil schnell mal Indices und Fremdschlüssel-Constraints verloren gehen.
Es gibt sicher gute Gründe dafür, warum DB2 DROP COLUMN nicht unterstützt - entsprechende Argumentationen findet man beim Googlen relativ schnell. Trotzdem erschwert DB2 leider agile Softwareentwicklung deutlich mehr als die anderen relationalen Datenbanksysteme.
Post bewerten
Atom.xml