Vergelijking en selectie van datasystemen voor migratie
Het datamodel tijdens het ontwikkelingsproces verandert, en op een bepaald moment komt het niet meer overeen met de database. Uiteraard kan de database worden verwijderd, waarna ORM een nieuwe versie zal aanmaken die overeenkomt met het model, maar deze procedure leidt tot verlies van bestaande gegevens. De functie van het migratiesysteem is dus om, als gevolg van schemawijzigingen, het te synchroniseren met het datamodel in de applicatie zonder verlies van bestaande gegevens.
In dit artikel willen we verschillende tools voor database-migratiebeheer bespreken. We hopen dat dit overzicht nuttig zal zijn voor ontwikkelaars die met dergelijke keuzes worden geconfronteerd.
Task
In ons bedrijf is er momenteel actieve ontwikkeling van de volgende generatie product ā Docs Security Suite (DSS). De serverzijde wordt geschreven in .Net Core, en als DBMS wordt Entity Framework Core gebruikt. Bij het ontwerpen van de applicatie kiezen we voor de Code First aanpak.
Het domeinmodel van de applicatie wordt gelijktijdig door verschillende ontwikkelaars gecreĆ«erd ā ieder is verantwoordelijk voor zijn of haar logische deel van het systeem.
In de vorige generatie DSS werd de klassieke Entity Framework Migrations (EF 6) gebruikt als migratiebeheersysteem. Er waren echter enkele klachten hierover, de belangrijkste was dat EF een haalbare aanpak voor versieconflicten miste. Dit feit blijft ons storen tijdens bugfixing in het kader van ondersteuning, dus we hebben besloten om alternatieve opties te overwegen.
Als resultaat van de discussie zijn de volgende eisen voor het migratiebeheersysteem geformuleerd:
- Ondersteuning voor verschillende DBMS. MS SQL Server, PostgreSQL, Oracle zijn verplicht, maar mogelijk kunnen ook andere worden gebruikt.
- Werken met ORM. In eerste instantie was het gebruik van EF Core bedoeld, maar tijdens het ontwerpproces waren we bereid om ook andere ORM's te overwegen.
- Automatische generatie van migraties. Gezien de ontwikkeling met Code First willen we graag vermijden dat migraties handmatig moeten worden opgesteld.
- Versieconflicten. In een gedistribueerde ontwikkelingsomgeving kan EF Core bij het samenvoegen vastlopen op conflicten. Dit wordt een aanzienlijk probleem, omdat verschillende delen van de applicatie door verschillende ontwikkelaars worden gemaakt, waardoor veel tijd verloren gaat aan elk conflict.
- Uitgebreide documentatie en ondersteuning. Hier lijkt uitleg niet nodig.
- Gratis. De voorwaarde is relatief, aangezien we ook bereid zijn om systemen te overwegen die niet zo duur zijn of dure, maar perfecte gebruikservaringen bieden.
Na een kort onderzoek zijn de volgende opties gevonden en als wenselijk beschouwd voor overweging:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
En nu wat meer in detail
Natuurlijk was dit de eerste en belangrijkste optie om te overwegen. Een native tool die out-of-the-box werkt zonder enige franje. Een overvloed aan documentatie, zowel officiƫle als minder officiƫle, eenvoud, enzovoorts. Echter, de klachten die aan de klassieke EF werden gesteld, zijn ook volledig van toepassing op EF Core.
Dus de voordelen van EF Core zijn:
- Ondersteuning van Microsoft, documentatie, ook in het Russisch, een enorme community.
- Automatische migratiegeneratie op basis van CodeFirst.
- In vergelijking met EF 6 wordt er in EF Core nu geen snapshot van de database opgeslagen. Bij het werken met EF Core in Code First is het nu niet noodzakelijk om de database te implementeren.
- Omdat we vanuit Code First werken, is het mogelijk om Ć©Ć©n migratie aan te houden voor alle vereiste gegevensproviders.
- Met betrekking tot providers wordt zowel PostgreSQL als Oracle, enzovoort, ondersteund, en zelfs - MS SQL Server š.
Maar ook de nadelen:
- De oplossing van conflicten blijft op hetzelfde niveau. Het is noodzakelijk om een volgorde van migraties te bouwen en snapshots van de database bij te werken.
- Afhankelijkheid van de modellen waarop migraties zijn gebaseerd.
DbUp
DbUp is een .NET-bibliotheek die via NuGet wordt geĆÆnstalleerd en helpt bij het toepassen van wijzigingen op SQL Server. Het houdt bij welke wijzigingsscripts al zijn uitgevoerd en voert de scripts uit die nodig zijn om de database bij te werken. De bibliotheek is voortgekomen uit een open-source blogengine-project op ASP.NET en is beschikbaar onder de MIT-licentie, terwijl de code op GitHub staat. Migraties worden beschreven met T-SQL.
Wat zijn hier de voordelen:
- Ondersteuning voor een groot aantal databases (MS SQL Server, PostgreSQL, MySQL).
- Aangezien scripts in T-SQL worden geschreven, zien ze er vrij eenvoudig uit.
- Conflicten worden ook opgelost met behulp van SQL.
En de nadelen:
- Ondanks de verscheidenheid aan ondersteunde databases, is Oracle daar niet bij inbegrepen.
- Werkt niet samen met ORM.
- Scripts schrijven in T-SQL āmet de handā is niet wat wij voor ogen hadden.
- De documentatie en community zijn middelmatig, hoewel ze mogelijk niet nodig zijn bij het schrijven van SQL-scripts.
RoundhousE
Dit migratiebeheertool, verspreid onder de Apache 2.0-licentie, werkt net als de vorige op de T-SQL migratiemotor. Blijkbaar hebben de ontwikkelaars de nadruk gelegd op het oplossen van technische problemen met DBMS-ondersteuning, in plaats van op het creƫren van een comfortabel ontwikkelingsproces.
Voordelen:
- Ondersteunt de benodigde DBMS'en (inclusief Oracle)
Nadelen:
- Oracle (en ook de verouderde Access) wordt niet ondersteund op .NET Core, alleen op .NET Full Framework.
- Werkt niet met ORM
- Er is nog minder documentatie dan bij het vorige hulpmiddel
- Opnieuw worden migraties geschreven met scripts
ThinkingHome.Migrator
Een tool voor versie-migratie van databaseschema's voor het .NET Core-platform, verspreid onder de MIT-licentie. .
Voordelen:
- Afgemeten op .NET Core
- Branching-migratiestructuur is geĆÆmplementeerd
- Migratielogging is geĆÆmplementeerd
Nadelen:
- Laatste update ā een jaar geleden. Blijkbaar wordt het project niet meer ondersteund.
- Oracle wordt niet ondersteund (in het artikel wordt vermeld dat dit komt door het ontbreken van een stabiele implementatie op .NET Core ā maar dit was een jaar geleden).
- Autogeneratie van migraties ontbreekt
Over het algemeen ziet het project er veelbelovend uit, vooral als het zich zou ontwikkelen, maar we moesten hier en nu een beslissing nemen.
Fluent Migrator
Het meest populaire migratiewerktuig met een grote schare fans. Verspreid onder de Apache 2.0-licentie. Zoals vermeld in de beschrijving, is het een migratieplatform voor .NET, vergelijkbaar met Ruby on Rails Migrations. Wijzigingen in het databaseschema worden beschreven in klassen in C#.
Hier zijn enkele voordelen:
- Ondersteuning voor de vereiste DBMS'en
- Ondersteuning voor .NET Core
- Een grote, actieve community
- Migratieconflicten worden sequentieel opgelost ā migraties hebben een uitvoeringsvolgorde. Bovendien, als er een conflict is rond een entiteit, wordt de oplossing tijdens het mergen van de code op dezelfde manier toegepast als in de rest van de code.
- Er zijn profielen die worden uitgevoerd na een succesvolle migratie en aanvullende servicefuncties kunnen bevatten. De laatste update was een maand geleden, wat betekent dat het project actief is.
Wat de nadelen betreft, zijn er:
- Autogeneratie van migraties ontbreekt
- Geen verbinding met EF-modellen
- Geen snapshots van de database
Wat was onze keuze?
De meest verhitte discussies deden zich voor rond twee parameters: autogeneratie van migraties en een redelijk conflictoplossingsmechanisme. Andere factoren waren veel minder verontrustend. Uiteindelijke besloot het team tijdens de discussie om in het nieuwe project Fluent Migrator te gebruiken. Immers, de oplossing voor conflicten zal op de lange termijn veel meer voordelen opleveren.
Conclusies
Natuurlijk zijn er geen perfecte tools. Ook wij moesten prioriteiten stellen in onze 'wensen'. Voor andere teams en andere taken kunnen echter andere factoren doorslaggevend blijken te zijn. We hopen dat dit artikel je helpt om een keuze te maken.
Bron: habr.com
