Vergelijking en selectie van datamigratiesystemen

Vergelijking en selectie van datamigratiesystemen

Vergelijking en selectie van datamigratiesystemen

Het datamodel heeft de neiging te veranderen tijdens het ontwikkelingsproces en komt op een gegeven moment niet meer overeen met de database. Natuurlijk kan de database worden verwijderd en dan zal de ORM een nieuwe versie maken die overeenkomt met het model, maar deze procedure zal leiden tot het verlies van bestaande gegevens. De functie van het migratiesysteem is dus om ervoor te zorgen dat het, als gevolg van een schemawijziging, wordt gesynchroniseerd met het datamodel in de applicatie zonder bestaande gegevens te verliezen.

In dit artikel willen we verschillende tools bekijken voor het beheren van databasemigraties. We hopen dat deze recensie nuttig zal zijn voor ontwikkelaars die voor een soortgelijke keuze staan.

Taak

Ons bedrijf is momenteel actief bezig met de ontwikkeling van de volgende generatie producten: Docs Security Suite (DSS). Het servergedeelte is geschreven in .Net Core en Entity Framework Core wordt gebruikt als DBMS. Bij het ontwerpen van een applicatie hanteren wij de Code First aanpak.

Het applicatiedomeinmodel wordt tegelijkertijd door meerdere ontwikkelaars gemaakt - elk is verantwoordelijk voor zijn eigen logische deel van het systeem.

De vorige generatie DSS gebruikte het klassieke Entity Framework Migrations (EF 6) als migratiebeheersysteem. Er zijn echter enkele klachten tegen dit systeem ontstaan, waarvan de belangrijkste is dat EF geen verstandige aanpak heeft om versieconflicten op te lossen. Dit feit irriteert ons nog steeds bij het oplossen van bugs als onderdeel van de ondersteuning, dus hebben we besloten alternatieve opties te overwegen.

Als resultaat van de discussie zijn de volgende vereisten voor het migratiebeheersysteem gevormd:

  1. Ondersteuning voor verschillende DBMS'en. MS SQL Server, PostgreSQL, Oracle zijn vereist, maar het is potentieel mogelijk om andere te gebruiken
  2. Werken met ORM. Aanvankelijk was het de bedoeling om EF Core te gebruiken, maar in de ontwerpfase waren we bereid andere ORM's te overwegen
  3. Automatisch genereren van migraties. Rekening houdend met de ontwikkeling van Code First, zou ik de noodzaak willen vermijden om migraties “met de hand te schrijven”.
  4. Versieconflicten. In een gedistribueerde ontwikkelomgeving kan EF Core bij het samenvoegen last krijgen van conflicten. Dit wordt een groot probleem omdat verschillende delen van de applicatie door verschillende ontwikkelaars zijn gemaakt, dus je moet veel tijd aan elk deel besteden.
  5. Geavanceerde documentatie en ondersteuning. Hier lijkt ons geen uitleg nodig
  6. Vrij. Het criterium is voorwaardelijk, aangezien systemen niet erg duur of duur zijn, maar qua gemak ideaal, waren we ook bereid om te overwegen

Als resultaat van wat onderzoek zijn de volgende opties gevonden en wenselijk geacht om te overwegen:

  1. EF-kernmigraties
  2. DBup
  3. RoundhouseE
  4. ThinkingHome.Migrator
  5. Vloeiende migratie

En nu iets meer details

Vergelijking en selectie van datamigratiesystemen
EntityFramework-kernmigraties

Uiteraard was dit de eerste en belangrijkste optie om te kiezen. Een native instrument dat direct uit de doos werkt, zonder gedoe met een tamboerijn. Een grote hoeveelheid documentatie, officieel en niet zo, eenvoud, enz. De klachten over klassieke EF zijn echter ook behoorlijk relevant voor EF Core.

Zo worden de voordelen voor EF Core benadrukt:

  • Microsoft-ondersteuning, documentatie, ook in het Russisch, enorme community
  • Automatisch genereren van migraties op basis van CodeFirst
  • In vergelijking met EF 6 slaat EF Core niet langer een momentopname van de database op. Wanneer je met EF Core in Code First werkt, is het niet langer nodig om een ​​database in te zetten
  • Omdat we dansen vanuit Code First is het mogelijk om één migratie uit te voeren naar alle benodigde data access providers
  • Wat de providers betreft: PostgreSQL wordt ondersteund, Oracle wordt ondersteund, enz., enz., en zelfs MS SQL Server 

En ook de nadelen:

  • Conflictoplossing bleef op hetzelfde niveau. Het is noodzakelijk om migraties op volgorde te zetten en database-snapshots bij te werken
  • Afhankelijkheid van de modellen waarop de migraties worden gegenereerd

DbUp

Vergelijking en selectie van datamigratiesystemen
dbup.github.io

DbUp is een .NET-bibliotheek die door NuGet wordt geïnstalleerd en helpt wijzigingen naar SQL Server te pushen. Het houdt bij welke wijzigingsscripts al zijn uitgevoerd en voert de wijzigingsscripts uit die nodig zijn om de database bij te werken. De bibliotheek is ontstaan ​​uit een project voor een open source blogging-engine op ASP.NET en bestaat onder een MIT-licentie, en de code staat op GitHub. Migraties worden beschreven met behulp van T-SQL.

Wat zijn de voordelen:

  • Ondersteuning voor een groot aantal DBMS (MS SQL Server, PstgreSQL, MySQL)
  • Omdat de scripts in T-SQL zijn geschreven, zien ze er vrij eenvoudig uit
  • Conflicten worden ook opgelost met behulp van SQL

En de nadelen:

  • Met al de verscheidenheid aan ondersteunde DBMS'en is Oracle daar niet een van
  • Heeft geen interactie met ORM
  • Met de hand T-SQL-scripts schrijven is niet waar we op mikten
  • De documentatie en de gemeenschap zijn matig, hoewel ze voor het schrijven van SQL-scripts misschien niet nodig zijn.

RoundhouseE

Vergelijking en selectie van datamigratiesystemen
github.com/chucknorris/roundhouse

Deze migratiebeheertool, gedistribueerd onder de Apache 2.0-licentie, draait net als de vorige op de T-SQL-migratie-engine. Blijkbaar gaven de ontwikkelaars prioriteit aan het oplossen van technische problemen met betrekking tot DBMS-ondersteuning, in plaats van het creëren van een comfortabel ontwikkelingsproces.

Voors:

  • Ondersteunt het benodigde DBMS (inclusief Oracle)

Tegens:

  • Oracle (evenals Access, wat voor ons niet relevant is) wordt niet ondersteund op .NET Core, alleen op .NET Full Framework
  • Werkt niet met ORM
  • Er is zelfs minder documentatie dan de vorige tool
  • Nogmaals: migraties worden geschreven door scripts

ThinkingHome.Migrator

Vergelijking en selectie van datamigratiesystemen

Een tool voor versiebeheer van databaseschemamigratie naar het .NET Core-platform, gedistribueerd onder de MIT-licentie. De ontwikkelaar schreef zelf bijna een jaar geleden over de nieuwste versie.

Voors:

  • Ontworpen voor .NET Core
  • Implementeerde een vertakkende reeks migraties
  • Migratieregistratie geïmplementeerd

Tegens:

  • Een jaar geleden voor het laatst bijgewerkt. Blijkbaar wordt het project niet ondersteund
  • Niet ondersteund door Oracle (in het artikel staat dat dit te wijten is aan het ontbreken van een stabiele implementatie voor .NET Core - maar dit is een jaar geleden)
  • Geen automatische generatie van migraties

Over het geheel genomen ziet het project er veelbelovend uit, vooral als het zich zou ontwikkelen, maar we moesten hier en nu een beslissing nemen.

Vloeiende migratie

Vergelijking en selectie van datamigratiesystemen
github.com/fluentmigrator/fluentmigrator

De populairste migratietool met een groot leger fans. Gedistribueerd onder de Apache 2.0-licentie. Zoals vermeld in de beschrijving is het een migratieframework voor .NET, vergelijkbaar met Ruby on Rails Migrations. Wijzigingen in het databaseschema worden beschreven in C#-klassen.

Er zijn hier voordelen:

  • Ondersteuning voor vereiste DBMS
  • .NET Core-ondersteuning
  • Grote ontwikkelde gemeenschap
  • Conflicten tussen migraties worden opeenvolgend opgelost; de volgorde van uitvoering van migraties wordt gespecificeerd. Als er bovendien een conflict rond één entiteit ontstaat, wordt dit bij het samenvoegen van de code op dezelfde manier opgelost als in de rest van de code
  • Er zijn profielen die worden uitgevoerd na een succesvolle migratie. En ze kunnen servicefuncties uitvoeren. De laatste update was een maand geleden, dat wil zeggen dat het project leeft

Wat betreft de minnen, hier zijn ze:

  • Geen automatische generatie van migraties
  • Geen verbinding met EF-modellen
  • Geen database-snapshots

Wat was onze keuze?

Vergelijking en selectie van datamigratiesystemen

De verhitte debatten draaiden om twee parameters: het automatisch genereren van migraties en het verstandig oplossen van conflicten. Andere factoren waren veel minder beangstigend. Als gevolg hiervan besloot het team, op basis van de resultaten van de discussie, om Fluent Migrator in het nieuwe project te gebruiken. Omdat het oplossen van conflicten in de toekomst veel meer voordelen zal opleveren.

Bevindingen

Natuurlijk bestaan ​​er geen perfecte tools. We moesten dus prioriteit geven aan onze ‘wensen’ om een ​​keuze te kunnen maken. Voor andere teams en andere taken kunnen echter andere factoren doorslaggevend zijn. Wij hopen dat dit artikel u helpt bij het maken van een keuze.

Bron: www.habr.com

Voeg een reactie