Porównanie i wybór systemów migracji danych
Model danych ma tendencję do zmiany w procesie rozwoju i w pewnym momencie nie odpowiada już bazie danych. Oczywiście bazę danych można usunąć i wtedy ORM utworzy nową wersję, która będzie pasować do modelu, jednak taka procedura doprowadzi do utraty istniejących danych. Zatem funkcją systemu migracji jest zapewnienie, że w wyniku zmiany schematu zostanie on zsynchronizowany z modelem danych w aplikacji bez utraty istniejących danych.
W tym artykule chcielibyśmy przyjrzeć się różnym narzędziom do zarządzania migracjami baz danych. Mamy nadzieję, że ta recenzja będzie przydatna dla programistów stojących przed podobnym wyborem.
Zadanie
Nasza firma aktualnie aktywnie rozwija kolejną generację produktu – Docs Security Suite (DSS). Część serwerowa jest napisana w .Net Core, a Entity Framework Core służy jako DBMS. Projektując aplikację stosujemy podejście Code First.
Model domeny aplikacji jest tworzony przez kilku programistów jednocześnie – każdy odpowiada za swoją własną logiczną część systemu.
Poprzednia generacja DSS korzystała z klasycznego Entity Framework Migrations (EF 6) jako systemu zarządzania migracjami. Jednak narosło kilka skarg na niego, z których główna dotyczyła tego, że EF brakuje rozsądnego podejścia do rozwiązywania konfliktów wersji. Fakt ten wciąż nas denerwuje, gdy naprawiamy błędy w ramach wsparcia, dlatego postanowiliśmy rozważyć alternatywne opcje.
W wyniku dyskusji powstały następujące wymagania dla systemu zarządzania migracjami:
- Obsługa różnych systemów DBMS. Wymagane są MS SQL Server, PostgreSQL, Oracle, ale potencjalnie możliwe jest użycie innych
- Praca z ORM-em. Początkowo planowano wykorzystać EF Core, jednak na etapie projektowania byliśmy gotowi rozważyć inne ORM-y
- Automatyczne generowanie migracji. Biorąc pod uwagę rozwój Code First, chciałbym uniknąć konieczności „pisania ręcznego” migracji
- Konflikty wersji. W rozproszonym środowisku programistycznym podczas scalania EF Core mogą wystąpić konflikty. Staje się to poważnym problemem, ponieważ różne części aplikacji są tworzone przez różnych programistów, więc trzeba poświęcić dużo czasu na każdą z nich.
- Zaawansowana dokumentacja i wsparcie. Wydaje nam się, że tutaj wyjaśnienia nie są potrzebne
- Bezpłatny. Kryterium jest warunkowe, ponieważ systemy nie są bardzo drogie ani drogie, ale idealne pod względem wygody, byliśmy również gotowi do rozważenia
W wyniku drobnych badań znaleziono następujące opcje, które uznano za pożądane do rozważenia:
- Migracje rdzenia EF
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Płynny Migrator
A teraz trochę więcej szczegółów
Oczywiście była to pierwsza i główna opcja do wyboru. Natywny instrument, który działa od razu po wyjęciu z pudełka, bez konieczności majstrowania przy tamburynie. Duża ilość dokumentacji, oficjalnej i nie takiej, prostota itp. Jednak skargi dotyczące klasycznego EF są również dość istotne w przypadku EF Core.
W ten sposób podkreślono zalety EF Core:
- Wsparcie Microsoft, dokumentacja, w tym w języku rosyjskim, ogromna społeczność
- Automatyczne generowanie migracji w oparciu o CodeFirst
- W porównaniu do EF 6, EF Core nie przechowuje już migawki bazy danych. Podczas pracy z EF Core w Code First nie jest już konieczne wdrażanie bazy danych
- Ponieważ tańczymy z Code First, możliwe jest przeprowadzenie jednej migracji do wszystkich wymaganych dostawców dostępu do danych
- Jeśli chodzi o dostawców, obsługiwany jest PostgreSQL, obsługiwany jest Oracle itp., itp., a nawet MS SQL Server
A także wady:
- Rozwiązywanie konfliktów pozostało na tym samym poziomie. Konieczne jest sekwencjonowanie migracji i aktualizacja migawek baz danych
- Zależność od modeli, na podstawie których generowane są migracje
DbUp
DbUp to biblioteka .NET instalowana przez NuGet i pomagająca wypychać zmiany do SQL Server. Śledzi, które skrypty zmian zostały już wykonane i uruchamia te, które są niezbędne do aktualizacji bazy danych. Biblioteka wyrosła z projektu silnika blogowego typu open source w ASP.NET i istnieje na licencji MIT, a kod znajduje się w GitHub. Migracje opisano przy użyciu języka T-SQL.
Jakie są zalety:
- Obsługa dużej liczby DBMS (MS SQL Server, PstgreSQL, MySQL)
- Ponieważ skrypty są napisane w języku T-SQL, wyglądają dość prosto
- Konflikty są również rozwiązywane za pomocą języka SQL
I wady:
- Przy całej różnorodności obsługiwanych systemów DBMS, Oracle nie jest jednym z nich
- Nie współdziała z ORM
- Ręczne pisanie skryptów T-SQL nie jest tym, do czego dążyliśmy
- Dokumentacja i społeczność są takie sobie, chociaż w przypadku pisania skryptów SQL mogą nie być konieczne.
RoundhouseE
To narzędzie do zarządzania migracjami, dystrybuowane na licencji Apache 2.0, podobnie jak poprzednie, działa na silniku migracji T-SQL. Najwyraźniej programiści priorytetowo postawili na rozwiązywanie problemów technicznych związanych z obsługą DBMS, zamiast na stworzenie wygodnego procesu programowania.
Plusy:
- Obsługuje niezbędny system DBMS (w tym Oracle)
Wady:
- Oracle (jak również Access, co dla nas jest nieistotne) nie jest obsługiwany na .NET Core, tylko na .NET Full Framework
- Nie działa z ORM-em
- Dokumentacji jest jeszcze mniej niż w przypadku poprzedniego narzędzia
- Powtarzam – migracje są pisane za pomocą skryptów
ThinkingHome.Migrator
Narzędzie do wersjonowanej migracji schematów baz danych na platformę .NET Core, dystrybuowane na licencji MIT. .
Plusy:
- Zaprojektowany dla platformy .NET Core
- Zaimplementowano rozgałęzioną sekwencję migracji
- Zaimplementowano rejestrowanie migracji
Wady:
- Ostatnia aktualizacja rok temu. Widocznie projekt nie jest wspierany
- Nieobsługiwane przez Oracle (w artykule napisano, że jest to spowodowane brakiem stabilnej implementacji dla .NET Core - ale to było rok temu)
- Brak automatycznego generowania migracji
Ogólnie projekt wygląda obiecująco, szczególnie jeśli miałby być rozwijany, ale decyzję musieliśmy podjąć tu i teraz.
Płynny Migrator
Najpopularniejsze narzędzie do migracji, posiadające dużą armię fanów. Dystrybuowany na licencji Apache 2.0. Jak stwierdzono w opisie, jest to framework migracyjny dla .NET, podobny do migracji Ruby on Rails. Zmiany w schemacie bazy danych opisano w klasach C#.
Tutaj są zalety:
- Wsparcie dla wymaganego systemu DBMS
- Obsługa platformy .NET Core
- Duża rozwinięta społeczność
- Konflikty pomiędzy migracjami rozwiązywane są sekwencyjnie – ustalana jest kolejność wykonywania migracji. Dodatkowo, jeśli wokół jednego podmiotu powstanie konflikt, to przy łączeniu kodu rozwiązuje się go w taki sam sposób, jak w pozostałej części kodu
- Istnieją profile, które są wykonywane po udanej migracji. No i mogą pełnić funkcje serwisowe.Ostatnia aktualizacja była miesiąc temu, czyli projekt żyje
Jeśli chodzi o minusy, oto one:
- Brak automatycznego generowania migracji
- Brak połączenia z modelami EF
- Brak migawek baz danych
Jaki był nasz wybór?
Gorące dyskusje toczyły się wokół dwóch parametrów – automatycznego generowania migracji i rozsądnego rozwiązywania konfliktów. Inne czynniki były znacznie mniej przerażające. W rezultacie, na podstawie wyników dyskusji, zespół zdecydował się na wykorzystanie Fluent Migrator w nowym projekcie. Ponieważ rozwiązywanie konfliktów w przyszłości przyniesie znacznie więcej korzyści.
odkrycia
Oczywiście nie ma narzędzi doskonałych. Musieliśmy więc ustalić priorytety naszych „chceń”, aby dokonać wyboru. Jednak w przypadku innych zespołów i innych zadań decydujące mogą być inne czynniki. Mamy nadzieję, że ten artykuł pomoże Ci dokonać wyboru.
Źródło: www.habr.com