Vergleich und Auswahl von Datentransfersystemen

Das Datenmodell im Entwicklungsprozess hat die Eigenschaft, sich zu ändern, und irgendwann stimmt es nicht mehr mit der Datenbank überein. Natürlich kann die DB gelöscht werden, und dann wird ORM eine neue Version erstellen, die dem Modell entspricht, aber ein solches Verfahren führt zu einem Verlust bestehender Daten. Somit besteht die Funktion des Migrationssystems darin, das Schema bei Änderungen mit dem Datenmodell in der Anwendung zu synchronisieren, ohne vorhandene Daten zu verlieren.
Im Rahmen dieses Artikels möchten wir verschiedene Werkzeuge zur Verwaltung von Datenbankmigrationen betrachten. Wir hoffen, dass dieser Überblick für Entwickler, die vor einer solchen Wahl stehen, nützlich sein wird.
Aufgabe
In unserem Unternehmen wird derzeit die aktive Entwicklung der nächsten Generation des Produkts – Docs Security Suite (DSS) – vorangetrieben. Der Backend-Teil wird auf .Net Core geschrieben, und als DBMS wird entsprechend Entity Framework Core verwendet. Bei der Anwendungsentwicklung verwenden wir den Ansatz Code First.
Das Domänenmodell der Anwendung wird gleichzeitig von mehreren Entwicklern erstellt – jeder ist für seinen logischen Teil des Systems verantwortlich.
In der vorherigen Generation von DSS wurde das klassische Entity Framework Migrations (EF 6) als Migrationsverwaltungssystem verwendet. Allerdings gab es einige Beschwerden, vor allem darüber, dass EF keinen praktikablen Ansatz zur Lösung von Versionskonflikten bietet. Diese Tatsache belastet uns immer noch beim Bugfixing im Rahmen der Unterstützung, weshalb beschlossen wurde, alternative Varianten in Betracht zu ziehen.
Nach der Besprechung wurden die folgenden Anforderungen an das Migrationsverwaltungssystem formuliert:
- Unterstützung verschiedener DBMS. MS SQL Server, PostgreSQL, Oracle ist erforderlich, aber potenziell sind auch andere nutzbar.
- Arbeiten mit ORM. Ursprünglich war die Verwendung von EF Core geplant, jedoch waren wir in der Planungsphase bereit, auch andere ORMs in Betracht zu ziehen.
- Automatische Generierung von Migrationen. Angesichts der Code First-Entwicklung möchten wir es gerne vermeiden, Migrationen „händisch“ zu schreiben.
- Versionskonflikte. In einer verteilten Entwicklung kann EF Core beim Merge-Konflikten auftreten. Dies wird zu einem erheblichen Problem, da verschiedene Teile der Anwendung von verschiedenen Entwicklern erstellt werden, weshalb viel Zeit für jeden Konflikt aufgewendet werden muss.
- Entwickelte Dokumentation und Unterstützung. Hier, so glauben wir, sind keine weiteren Erklärungen nötig.
- Kostenlosigkeit. Das Kriterium ist bedingt, da wir auch nicht sehr teure Systeme oder teure, aber ideale in der Benutzerfreundlichkeit, ebenfalls in Betracht ziehen würden.
Infolge einer kleinen Untersuchung wurden die folgenden Optionen gefunden und als wünschenswert für die Prüfung anerkannt:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Nun etwas detaillierter

Natürlich war dies die erste und wichtigste Wahl. Ein natives Tool, das sofort ohne besondere Anpassungen funktioniert. Eine große Menge an Dokumentation, sowohl offizielle als auch weniger offizielle, Einfachheit usw. Dennoch sind die Vorwürfe, die gegen das klassische EF erhoben wurden, auch für EF Core durchaus relevant.
Somit ergeben sich für EF Core folgende Vorteile:
- Unterstützung von Microsoft, Dokumentation, auch auf Russisch, eine riesige Community.
- Automatische Erstellung von Migrationen basierend auf CodeFirst.
- Im Vergleich zu EF 6 wird in EF Core nun kein Datenbank-Snapshot gespeichert. Bei der Verwendung von EF Core in Code First ist es nun nicht mehr erforderlich, die Datenbank zu starten.
- Da wir von Code First ausgehen, gibt es die Möglichkeit, eine Migration für alle erforderlichen Datenzugriffsanbieter zu führen.
- Was die Anbieter angeht - sowohl PostgreSQL als auch Oracle usw., und sogar - MS SQL Server :)
Und auch Nachteile:
- Die Konfliktlösung blieb auf dem gleichen Niveau. Es müssen Mangementfolgen von Migrationen aufgebaut werden und die Datenbank-Snapshots aktualisiert werden.
- Abhängigkeit von den Modellen, auf deren Grundlage die Migrationen generiert wurden.
DbUp

DbUp ist eine .NET-Bibliothek, die über NuGet installiert wird und hilft, Änderungen an SQL Server anzuwenden. Sie verfolgt, welche Änderungs-Skripte bereits ausgeführt wurden, und führt diejenigen aus, die zur Aktualisierung der DB erforderlich sind. Die Bibliothek ist aus einem Open-Source-Blog-Engine-Projekt auf ASP.NET hervorgegangen und existiert unter der MIT-Lizenz, der Code befindet sich auf GitHub. Migrationen werden mithilfe von T-SQL beschrieben.
Welche Vorteile gibt es?:
- Unterstützung einer großen Anzahl von DBMS (MS SQL Server, PostgreSQL, MySQL).
- Da die Skripte in T-SQL geschrieben werden, sehen sie ziemlich einfach aus.
- Konflikte werden ebenfalls mithilfe von SQL gelöst.
Und die Nachteile:
- Trotz der Vielzahl unterstützter DBMS gehört Oracle nicht dazu.
- Keine Interaktion mit ORM.
- Das Schreiben von Skripten in T-SQL 'manuell' ist nicht das, wonach wir gestrebt haben.
- Die Dokumentation und die Community sind eher schwach, obwohl sie beim Verfassen von SQL-Skripten möglicherweise nicht erforderlich sind.
RoundhousE

Dieses Migrationsmanagement-Tool, das unter der Lizenz Apache 2.0 verbreitet wird, arbeitet wie das vorherige mit der T-SQL-Migrationsengine. Anscheinend lag den Entwicklern die Lösung technischer Probleme im Hinblick auf die Unterstützung von DBMS am Herzen, nicht die Schaffung eines komfortablen Entwicklungsprozesses.
Vorteile:
- Unterstützt die erforderlichen DBMS (einschließlich Oracle)
Nachteile:
- Oracle (und auch der für uns irrelevante Access) wird nicht auf .NET Core unterstützt, nur auf .NET Full Framework.
- Funktioniert nicht mit ORM
- Die Dokumentation ist noch weniger umfangreich als bei dem vorherigen Tool.
- Wie auch immer – die Migrationen werden als Skripte geschrieben.
ThinkingHome.Migrator
![]()
Ein Tool für die versionierte Migration von Datenbankschemata für die .NET Core-Plattform, das unter der Lizenz MIT verbreitet wird. .
Vorteile:
- Auf .NET Core zugeschnitten.
- Eine verzweigte Migrationssequenz wurde implementiert.
- Migrationslogging wurde implementiert.
Nachteile:
- Das letzte Update war vor einem Jahr. Anscheinend wird das Projekt nicht mehr unterstützt.
- Unterstützt kein Oracle (im Artikel wird angegeben, dass dies aufgrund der fehlenden stabilen Implementierung unter .NET Core der Fall ist – das war vor einem Jahr).
- Automatische Migrationserstellung fehlt.
Insgesamt sieht das Projekt vielversprechend aus, insbesondere wenn es weiterentwickelt wird, aber wir mussten hier und jetzt eine Entscheidung treffen.
Fluent Migrator

Das beliebteste Migrationstool mit einer großen Anhängerschaft. Verbreitet unter der Lizenz Apache 2.0. Wie in der Beschreibung angegeben, ist es eine Migrationsplattform für .NET, die Ruby on Rails Migrations ähnlich ist. Änderungen am DB-Schema werden in C#-Klassen beschrieben.
Hier gibt es Vorteile:
- Unterstützung für die erforderlichen DBMS
- Unterstützung für .NET Core
- Eine große, aktive Community
- Konflikte bei Migrationen werden sequenziell gelöst – bei Migrationen wird die Ausführungsreihenfolge angegeben. Wenn ein Konflikt um eine Entität auftritt, wird dessen Lösung beim Mergen des Codes genauso durchgeführt wie bei anderem Code.
- Es gibt Profile, die nach erfolgreicher Ausführung der Migration ausgeführt werden und serviceorientierte Funktionen enthalten können. Das letzte Update war vor einem Monat, was bedeutet, dass das Projekt aktiv ist.
Was die Nachteile betrifft, so sind hier:
- Automatische Migrationserstellung fehlt.
- Keine Verbindung zu EF-Modellen
- Es gibt keine Datenbankschnappschüsse.
Wie fiel unsere Wahl aus?

Die heftigsten Diskussionen entbrannten um zwei Parameter – die Auto-Generierung von Migrationen und eine vernünftige Lösung für Konflikte. Andere Faktoren waren weit weniger beunruhigend. Letztlich entschloss sich das Team nach den Diskussionen, im neuen Projekt Fluent Migrator zu verwenden. Denn die Lösung von Konflikten wird langfristig viel mehr Vorteile bringen.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Natürlich gibt es keine perfekten Werkzeuge. So mussten auch wir bei der Auswahl Prioritäten in unseren „Wünschen“ setzen. Für andere Teams und Aufgaben können jedoch andere Faktoren entscheidend sein. Wir hoffen, dass Ihnen dieser Artikel bei der Entscheidungsfindung hilft.
Quelle: habr.com
