Verglach a Auswiel vun Daten Migratioun Systemer
Den Datemodell tendéiert während dem Entwécklungsprozess z'änneren, an iergendwann entsprécht et net méi der Datebank. Natierlech kann d'Datebank geläscht ginn, an dann erstellt den ORM eng nei Versioun, déi dem Modell entsprécht, awer dës Prozedur féiert zum Verloscht vun existente Donnéeën. Also ass d'Funktioun vum Migratiounssystem fir sécherzestellen datt, als Resultat vun enger Schema Ännerung, et mam Datemodell an der Applikatioun synchroniséiert gëtt ouni existent Daten ze verléieren.
An dësem Artikel wëlle mir verschidde Tools kucken fir Datebankmigratiounen ze managen. Mir hoffen datt dës Iwwerpréiwung nëtzlech ass fir Entwéckler déi mat enger ähnlecher Wiel konfrontéiert sinn.
Objective
Eis Gesellschaft entwéckelt de Moment aktiv déi nächst Generatioun vum Produkt - Docs Security Suite (DSS). De Server Deel ass an .Net Core geschriwwen, an Entity Framework Core gëtt als DBMS benotzt. Wann Dir eng Applikatioun designt, benotze mir de Code First Approche.
Den Applikatiouns Domain Modell gëtt vu verschiddenen Entwéckler zur selwechter Zäit erstallt - jidderee ass verantwortlech fir hiren eegene logeschen Deel vum System.
Déi viregt Generatioun vun DSS huet déi klassesch Entity Framework Migrations (EF 6) als Migratiounsmanagementsystem benotzt. Wéi och ëmmer, e puer Reklamatiounen hu sech dergéint gesammelt, déi Haaptschwieregkeet ass datt EF eng verstänneg Approche feelt fir Versiounskonflikter ze léisen. Dës Tatsaach stéiert eis nach ëmmer wann Dir Bugs als Deel vun der Ënnerstëtzung fixéiert, also hu mir decidéiert alternativ Optiounen ze berücksichtegen.
Als Resultat vun der Diskussioun goufen déi folgend Ufuerderunge fir de Migratiounsmanagementsystem geformt:
- Ënnerstëtzung fir verschidde DBMSs. MS SQL Server, PostgreSQL, Oracle sinn erfuerderlech, awer et ass potenziell méiglech anerer ze benotzen
- Schafft mat ORM. Am Ufank war et geplangt fir EF Core ze benotzen, awer an der Designstadium ware mir prett aner ORMs ze berücksichtegen
- Auto-Generatioun vu Migratiounen. Wann Dir d'Entwécklung vum Code als éischt berücksichtegt, géif ech gär d'Noutwennegkeet vermeiden fir Migratiounen ze "handschreiwen"
- Versioun Konflikter. An engem verdeelt Entwécklungsëmfeld, beim Fusioun, kann EF Core vu Konflikter leiden. Dëst gëtt e wesentleche Problem well verschidden Deeler vun der Applikatioun vu verschiddenen Entwéckler erstallt ginn, also musst Dir vill Zäit op all
- Fortgeschratt Dokumentatioun an Ënnerstëtzung. Hei, et schéngt eis, brauch keng Erklärung
- fräi. De Critère ass bedingt, well Systemer net ganz deier oder deier sinn, awer ideal fir Komfort, ware mir och bereet ze berücksichtegen
Als Resultat vun e bësse Fuerschung goufen déi folgend Optiounen fonnt a wënschenswäert fonnt fir ze berücksichtegen:
- EF Core Migrations
- DBup
- Roundhouse E
- ThinkingHome.Migrator
- Fléissend Migrator
An elo e bësse méi Detail
Natierlech war dëst déi éischt an Haaptoptioun fir ze wielen. E gebierteg Instrument dat aus der Këscht funktionnéiert ouni mat enger Tambourin ze fidderen. Eng grouss Quantitéit vun Dokumentatioun, offiziell an net esou, Einfachheet, etc. Wéi och ëmmer, d'Reklamatiounen iwwer klassesch EF sinn och ganz relevant fir EF Core.
Also sinn d'Virdeeler fir EF Core beliicht:
- Microsoft Ënnerstëtzung, Dokumentatioun, dorënner Russesch, grouss Communautéit
- Automatesch Generatioun vu Migratiounen baséiert op CodeFirst
- Am Verglach mam EF 6 späichert EF Core net méi e Snapshot vun der Datebank. Wann Dir mat EF Core am Code First schafft, ass et net méi néideg eng Datebank z'installéieren
- Well mir aus Code First danzen, ass et méiglech eng Migratioun un all erfuerderlech Datezougang Ubidder ze maachen
- Wat d'Provider ugeet, gëtt PostgreSQL ënnerstëtzt, Oracle gëtt ënnerstëtzt, asw., etc., a souguer MS SQL Server
An och d'Nodeeler:
- Konfliktléisung blouf um selwechten Niveau. Et ass néideg fir Migratiounen ze sequenzéieren an Datebank Snapshots ze aktualiséieren
- Ofhängegkeet vun de Modeller op deenen d'Migratiounen generéiert ginn
DbUp
DbUp ass eng .NET Bibliothéik déi vun NuGet installéiert ass an hëlleft Ännerungen op SQL Server ze drécken. Et verfollegt wéi eng Ännerungsskripter scho gemaach goufen a leeft déi, déi néideg sinn fir d'Datebank ze aktualiséieren. D'Bibliothéik ass aus engem Projet fir en Open Source Blogging Engine op ASP.NET gewuess an existéiert ënner enger MIT Lizenz, an de Code ass op GitHub. Migratioune gi beschriwwe mat T-SQL.
Wat sinn d'Virdeeler:
- Ënnerstëtzung fir eng grouss Zuel vun DBMS (MS SQL Server, PstgreSQL, MySQL)
- Zënter datt d'Skripte an T-SQL geschriwwe sinn, si se ganz einfach aus
- Konflikter ginn och mat SQL geléist
An d'Nodeeler:
- Mat all der Varietéit vun ënnerstëtzten DBMSen ass Oracle net ee vun hinnen
- Interagéiert net mat ORM
- T-SQL Scripte mat der Hand schreiwen ass net dat wat mir gezielt hunn
- D'Dokumentatioun an d'Gemeinschaft si sou-sou, och wann et a punkto SQL Scripte schreift se vläicht net néideg sinn.
Roundhouse E
Dëst Migratiounsmanagement Tool, verdeelt ënner der Apache 2.0 Lizenz, wéi déi virdrun, leeft op der T-SQL Migratiounsmotor. Anscheinend hunn d'Entwéckler prioritär technesch Probleemer betreffend DBMS Support léisen, anstatt e bequemen Entwécklungsprozess ze kreéieren.
Pros:
- Ënnerstëtzt déi néideg DBMS (och Oracle)
Muecht:
- Oracle (wéi och Access, wat fir eis irrelevant ass) gëtt net op .NET Core ënnerstëtzt, nëmmen op .NET Full Framework
- Schafft net mat ORM
- Et gëtt nach manner Dokumentatioun wéi dat viregt Tool
- Erëm - Migratioune gi vu Skripte geschriwwen
ThinkingHome.Migrator
En Tool fir Versioune vun der Datebankschemamigratioun op d'.NET Core Plattform, verdeelt ënner der MIT Lizenz. .
Pros:
- Entworf fir .NET Core
- Ëmgesat eng branching Sequenz vu Migratiounen
- Ëmgesat Migratioun Logged
Muecht:
- Fir d'lescht virun engem Joer aktualiséiert. Anscheinend gëtt de Projet net ënnerstëtzt
- Net ënnerstëtzt vun Oracle (den Artikel seet datt dëst wéinst dem Mangel un enger stabiler Implementatioun fir .NET Core ass - awer dëst ass virun engem Joer)
- Keng automatesch Generatioun vu Migratiounen
Insgesamt gesäit de Projet villverspriechend aus, virun allem wann en sech géif entweckelen, mä mir hu missen hei an elo eng Entscheedung treffen.
Fléissend Migrator
De beléifste Migratiounsinstrument mat enger grousser Arméi vu Fans. Verdeelt ënner der Apache 2.0 Lizenz. Wéi an der Beschreiwung uginn, ass et e Migratiounskader fir .NET, ähnlech wéi Ruby on Rails Migrations. Ännerungen un der Datebank Schema sinn an C # Klassen beschriwwen.
Et gi Virdeeler hei:
- Ënnerstëtzung fir erfuerderlech DBMS
- .NET Core Ënnerstëtzung
- Grouss entwéckelt Gemeinschaft
- Konflikter tëscht Migratiounen ginn sequenziell geléist - d'Uerdnung vun der Ausféierung vun de Migratiounen gëtt spezifizéiert. Zousätzlech, wann e Konflikt ronderëm eng Entitéit entsteet, wann de Code fusionéiert, gëtt et op déiselwecht Manéier geléist wéi am Rescht vum Code
- Et gi Profiler déi no enger erfollegräicher Migratioun ausgefouert ginn. A si kënnen Service Funktiounen droen.Déi lescht Update war virun engem Mount, dat heescht, de Projet leeft
Wat d'Minusen ugeet, hei sinn se:
- Keng automatesch Generatioun vu Migratiounen
- Keng Verbindung mat EF Modeller
- Keng Datebank Schnappschëss
Wat war eise Choix?
Déi gehëtzt Debatten hunn sech ëm zwee Parameteren dréit - automatesch Generatioun vu Migratiounen a vernünfteg Léisung vu Konflikter. Aner Faktore ware vill manner erschreckend. Als Resultat, baséiert op d'Resultater vun der Diskussioun, huet d'Team decidéiert Fluent Migrator am neie Projet ze benotzen. Well Konflikter léisen an Zukunft wäert vill méi Virdeeler bréngen.
Conclusiounen
Natierlech ginn et keng perfekt Tools. Also hu mir eis "Wënsch" prioritär ze stellen fir e Choix ze maachen. Wéi och ëmmer, fir aner Teams an aner Aufgaben kënnen aner Faktoren entscheedend sinn. Mir hoffen dësen Artikel hëlleft Iech e Choix ze maachen.
Source: will.com