16. Jun 2025
Lesedauer 4 Min.
DWX hakt nach: Was tun, wenn EF Core Migrations nicht mehr reicht?
Konferenz
Komplexe Datenbankmigrationen sind weit von einfachen Add-Migration-Befehlen entfernt. Leonhard Fischl zeigt auf der Developer Week, wie man auch dann souverän bleibt, wenn EF Core an seine Grenzen stößt. Im Interview gibt er erste Hinweise.
Leonhard Fischl ist erfahrener Full Stack-Entwickler mit Fokus auf komplexe Geschäftsprozesse im .NET-Umfeld. In über 15 Jahren als Softwareentwickler, Projektleiter und Softwarearchitekt hat er viele Datenbanken kommen und wachsen sehen – samt aller Herausforderungen. In seiner Session Beyond EF Core Migrations: Alternative Lösungen, wenn dieses Tool an seine Grenzen stößt geht er auf die Realitäten produktiver Datenbankmigrationen ein – mit Praxistipps, die weit über das hinausgehen, was man aus Tutorials kennt.Welche typischen Herausforderungen treten bei komplexen Strukturänderungen in produktiven Datenbanken auf, die über die Möglichkeiten von EF Core Migrations hinausgehen?
Leonhard Fischl: Bei komplexen Strukturänderungen in produktiven Datenbanken können Herausforderungen auftreten wie das Risiko von Ausfallzeiten, Datenverlust oder Inkonsistenzen. Meistens gibt es "historisch gewachsene" Strukturen, die nicht immer auf den ersten Blick nachvollziehbar sind. Außerdem kann es Vorgaben geben wie Namenskonventionen oder eine bestimmte Reihenfolge (alphabethisch) von Tabellenspalten. Mit einigen dieser Vorgaben können Tools wie EF Core umgehen.Eine Spalte mitten in einer Tabelle einzufügen, stellt die mir bekannten Werkzeuge vor große Herausforderungen. Auch das DB-Modell (inklusive SQL-Objekte wie Stored Procedures) dauerhaft mit der Datenbank synchron zu halten, kann zu einer Herausforderung werden und erfordert mindestens Abstimmungsbedarf mit den Verantwortlichen und eine sorgfältige Analyse und Planung von Änderungen und Rollouts - inklusive Rollback-Plan.
Welche alternativen Ansätze empfiehlst du, um Datenintegrität und Namenskonventionen bei komplexen Migrationen zuverlässig sicherzustellen?
Leonhard: Hier kann ich nur für mich beziehungsweise mein Kundenprojekt sprechen. Wir haben uns dazu entschieden - aus unterschiedlichsten Gründen - die Datenintegrität und Namenskonventionen via Skripte sicherzustellen. Für unsere Arbeit ist es wichtig, die volle Kontrolle über die DB Änderungen zu haben. Dazu gehören auch regelmäßige Strukturänderungen. Unterm Strich sind es Raw-SQL-Skripte, die teilautomatisiert erzeugt werden.Es gibt bereits gute Tools so zum Beispiel SQL Server Management Studio (SSMS), das bereits eine solide Basis beim Erzeugen dieser Skripte bietet. Bei großen Migrationsskripten nutzen wir immer das gleiche Schema als Basis ("scheußlich aber gleichmäßig"), um daraus mehrfach aufrufbare, stabile und performante Skripte zu bauen.Ein weiterer Grund für dieses Vorgehen ist der Single Point of Truth: Es gibt eine zentrale Stelle für die SQL-Skripte, die versioniert im Git abgelegt werden. Natürlich wissen wir auch, dass dieser manuelle Aufwand durch das Nutzen von weiteren Werkzeugen optimiert werden kann, zum Beispiel mit dbForge SQL Complete oder Copilot im neuen SSMS Version 21.Meine deutliche Empfehlung ist hier allerdings, das Grundwissen rund um diese Art von SQL-Skripte aufzubauen. In späteren Schritten lassen sich dann auch passende Tools nutzen, die es auf dem Markt bereits gibt.
Wie gehst du bei der mehrfachen Ausführung von Migrationsskripten vor, um Inkonsistenzen zu vermeiden?
Leonhard: Der Einsatz von Transaktionen ist hier entscheidend, um Inkonsistenzen zu vermeiden. Transaktionen stellen sicher, dass alle Änderungen atomar sind und bei einem Fehler zurückgerollt werden können, wodurch die Datenintegrität gewahrt bleibt. Auch der EXEC(...)-Befehl kann sehr hilfreich sein, um SQL-Befehle in einem Batch auszuführen. Um zu entscheiden, ob eine Änderung bereits durchgeführt wurde, helfen SQL Server eigene Objekte, zum Beispiel im systemeigenen Schema INFORMATION_SCHEMA. Diese können genutzt werden, um alle möglichen SQL-Objekte zu prüfen, Stichwort SELECT.
Ganz konkret: Existiert bereits die gewünschte neue Spalte Xyz? Wenn nein, soll das Skript zur Strukturänderung ausgeführt werden. Ansonsten reicht es, ein Art Log zu schreiben, das die Änderung bereits angewendet wurde. Warum ihr PRINT in größeren Migrationsskripten nicht verwenden sollt und was der große Vorteil von RAISERROR mit der NOWAIT-Option ist, erfahrt ihr dann in meiner Session auf der DWX.Dem kann man sich nur anschließen: Kommt in Leonhards Vortrag am Dienstag, 1. Juli 2025, um 16:00 Uhr auf der DWX Developer Week besuchen. Mehr Infos unter www.developer-week.de.
Leonhard Fischl: Bei komplexen Strukturänderungen in produktiven Datenbanken können Herausforderungen auftreten wie das Risiko von Ausfallzeiten, Datenverlust oder Inkonsistenzen. Meistens gibt es "historisch gewachsene" Strukturen, die nicht immer auf den ersten Blick nachvollziehbar sind. Außerdem kann es Vorgaben geben wie Namenskonventionen oder eine bestimmte Reihenfolge (alphabethisch) von Tabellenspalten. Mit einigen dieser Vorgaben können Tools wie EF Core umgehen.Eine Spalte mitten in einer Tabelle einzufügen, stellt die mir bekannten Werkzeuge vor große Herausforderungen. Auch das DB-Modell (inklusive SQL-Objekte wie Stored Procedures) dauerhaft mit der Datenbank synchron zu halten, kann zu einer Herausforderung werden und erfordert mindestens Abstimmungsbedarf mit den Verantwortlichen und eine sorgfältige Analyse und Planung von Änderungen und Rollouts - inklusive Rollback-Plan.
Welche alternativen Ansätze empfiehlst du, um Datenintegrität und Namenskonventionen bei komplexen Migrationen zuverlässig sicherzustellen?
Leonhard: Hier kann ich nur für mich beziehungsweise mein Kundenprojekt sprechen. Wir haben uns dazu entschieden - aus unterschiedlichsten Gründen - die Datenintegrität und Namenskonventionen via Skripte sicherzustellen. Für unsere Arbeit ist es wichtig, die volle Kontrolle über die DB Änderungen zu haben. Dazu gehören auch regelmäßige Strukturänderungen. Unterm Strich sind es Raw-SQL-Skripte, die teilautomatisiert erzeugt werden.Es gibt bereits gute Tools so zum Beispiel SQL Server Management Studio (SSMS), das bereits eine solide Basis beim Erzeugen dieser Skripte bietet. Bei großen Migrationsskripten nutzen wir immer das gleiche Schema als Basis ("scheußlich aber gleichmäßig"), um daraus mehrfach aufrufbare, stabile und performante Skripte zu bauen.Ein weiterer Grund für dieses Vorgehen ist der Single Point of Truth: Es gibt eine zentrale Stelle für die SQL-Skripte, die versioniert im Git abgelegt werden. Natürlich wissen wir auch, dass dieser manuelle Aufwand durch das Nutzen von weiteren Werkzeugen optimiert werden kann, zum Beispiel mit dbForge SQL Complete oder Copilot im neuen SSMS Version 21.Meine deutliche Empfehlung ist hier allerdings, das Grundwissen rund um diese Art von SQL-Skripte aufzubauen. In späteren Schritten lassen sich dann auch passende Tools nutzen, die es auf dem Markt bereits gibt.
Wie gehst du bei der mehrfachen Ausführung von Migrationsskripten vor, um Inkonsistenzen zu vermeiden?
Leonhard: Der Einsatz von Transaktionen ist hier entscheidend, um Inkonsistenzen zu vermeiden. Transaktionen stellen sicher, dass alle Änderungen atomar sind und bei einem Fehler zurückgerollt werden können, wodurch die Datenintegrität gewahrt bleibt. Auch der EXEC(...)-Befehl kann sehr hilfreich sein, um SQL-Befehle in einem Batch auszuführen. Um zu entscheiden, ob eine Änderung bereits durchgeführt wurde, helfen SQL Server eigene Objekte, zum Beispiel im systemeigenen Schema INFORMATION_SCHEMA. Diese können genutzt werden, um alle möglichen SQL-Objekte zu prüfen, Stichwort SELECT.
Ganz konkret: Existiert bereits die gewünschte neue Spalte Xyz? Wenn nein, soll das Skript zur Strukturänderung ausgeführt werden. Ansonsten reicht es, ein Art Log zu schreiben, das die Änderung bereits angewendet wurde. Warum ihr PRINT in größeren Migrationsskripten nicht verwenden sollt und was der große Vorteil von RAISERROR mit der NOWAIT-Option ist, erfahrt ihr dann in meiner Session auf der DWX.Dem kann man sich nur anschließen: Kommt in Leonhards Vortrag am Dienstag, 1. Juli 2025, um 16:00 Uhr auf der DWX Developer Week besuchen. Mehr Infos unter www.developer-week.de.
