Komparo kaj elekto de sistemoj de migrado de datumoj
La datummodelo emas ŝanĝiĝi dum la evoluprocezo, kaj iam ĝi ne plu respondas al la datumbazo. Kompreneble, la datumbazo povas esti forigita, kaj tiam la ORM kreos novan version, kiu kongruos kun la modelo, sed ĉi tiu proceduro kondukos al la perdo de ekzistantaj datumoj. Tiel, la funkcio de la migra sistemo estas certigi ke, kiel rezulto de skemŝanĝo, ĝi estas sinkronigita kun la datummodelo en la aplikaĵo sen perdi ekzistantajn datumojn.
En ĉi tiu artikolo, ni ŝatus rigardi diversajn ilojn por administri datumbazajn migradojn. Ni esperas, ke ĉi tiu recenzo estos utila por programistoj alfrontantaj similan elekton.
Objektivo
Nia kompanio nuntempe aktive disvolvas la sekvan generacion de produkto - Docs Security Suite (DSS). La servila parto estas skribita en .Net Core, kaj Entity Framework Core estas uzata kiel DBMS. Dum desegnado de aplikaĵo, ni uzas la aliron Code First.
La aplikaĵa domajna modelo estas kreita de pluraj programistoj samtempe - ĉiu respondecas pri sia propra logika parto de la sistemo.
La antaŭa generacio de DSS uzis la klasikan Entity Framework Migrations (EF 6) kiel la migradadministradsistemon. Tamen, kelkaj plendoj akumuliĝis kontraŭ ĝi, la ĉefa estas ke al EF mankas prudenta aliro por solvi versiokonfliktojn. Ĉi tiu fakto ankoraŭ ĝenas nin kiam riparas cimojn kiel parto de subteno, do ni decidis konsideri alternativajn elektojn.
Kiel rezulto de la diskuto, la sekvaj postuloj por la migradmastruma sistemo estis formitaj:
- Subteno por diversaj DBMSoj. MS SQL Server, PostgreSQL, Oracle estas postulataj, sed eble eblas uzi aliajn
- Laborante kun ORM. Komence, estis planite uzi EF Core, sed en la dezajnstadio ni pretis konsideri aliajn ORMojn.
- Aŭto-generado de migradoj. Konsiderante la evoluon de Code First, mi ŝatus eviti la bezonon "manskribi" migradojn
- Versiokonfliktoj. En distribuita evolumedio, dum kunfandado, EF Core povas suferi konfliktojn. Ĉi tio fariĝas grava problemo ĉar malsamaj partoj de la aplikaĵo estas kreitaj de malsamaj programistoj, do vi devas pasigi multe da tempo por ĉiu.
- Altnivela dokumentado kaj subteno. Ĉi tie, ŝajnas al ni, ne necesas klarigo
- Senpaga. La kriterio estas kondiĉa, ĉar sistemoj ne estas tre multekostaj aŭ multekostaj, sed idealaj en oportuno, ni ankaŭ pretis konsideri
Kiel rezulto de iom da esplorado, la sekvaj opcioj estis trovitaj kaj trovitaj dezirindaj por konsidero:
- EF Kernaj Migradoj
- DBup
- TrafikdomoE
- ThinkingHome.Migrator
- Flua Migranto
Kaj nun iom pli da detaloj
Kompreneble, ĉi tio estis la unua kaj ĉefa elekto por elekti. Indiĝena instrumento kiu funkcias el la skatolo sen iu ajn ludado per tamburino. Granda kvanto da dokumentaro, oficiala kaj ne tiel, simpleco, ktp. Tamen, la plendoj faritaj pri klasika EF ankaŭ estas sufiĉe gravaj por EF Core.
Tiel, la avantaĝoj por EF Core estas emfazitaj:
- Mikrosofta subteno, dokumentado, inkluzive en la rusa, grandega komunumo
- Aŭtomata generacio de migradoj bazitaj sur CodeFirst
- Kompare kun EF 6, EF Core ne plu stokas momentfoton de la datumbazo. Kiam vi laboras kun EF Core en Code First, ne plu necesas disfaldi datumbazon
- Ĉar ni dancas de Code First, eblas fari unu migradon al ĉiuj postulataj provizantoj de aliro al datumoj
- Koncerne provizantoj, PostgreSQL estas subtenata, Oracle estas subtenata ktp, ktp., kaj eĉ MS SQL Server
Kaj ankaŭ la malavantaĝoj:
- Konfliktsolvado restis sur la sama nivelo. Necesas sekvenci migradojn kaj ĝisdatigi datumbazajn momentfotojn
- Dependeco de la modeloj sur kiuj la migradoj estas generitaj
DbUp
DbUp estas .NET-biblioteko instalita de NuGet kaj helpas puŝi ŝanĝojn al SQL-Servilo. Ĝi kontrolas, kiuj ŝanĝaj skriptoj jam estis ekzekutitaj kaj kuras tiujn, kiuj estas necesaj por ĝisdatigi la datumbazon. La biblioteko elkreskis el projekto por malfermfonta bloga motoro sur ASP.NET kaj ekzistas sub MIT-licenco, kaj la kodo estas sur GitHub. Migradoj estas priskribitaj uzante T-SQL.
Kio estas la avantaĝoj:
- Subteno por granda nombro da DBMS (MS SQL Server, PstgreSQL, MySQL)
- Ĉar la skriptoj estas skribitaj en T-SQL, ili aspektas sufiĉe simplaj
- Konfliktoj ankaŭ estas solvitaj per SQL
Kaj la malavantaĝoj:
- Kun la tuta vario de subtenataj DBMSoj, Oracle ne estas unu el ili
- Ne interagas kun ORM
- Skribi T-SQL-skriptojn mane ne estas tio, kion ni celis
- La dokumentaro kaj komunumo estas tiel, kvankam rilate al verkado de SQL-skriptoj ili eble ne estas necesaj.
TrafikdomoE
Ĉi tiu migrada administra ilo, distribuita sub la permesilo Apache 2.0, kiel la antaŭa, funkcias per la migra motoro T-SQL. Ŝajne, la programistoj prioritatis solvi teknikajn problemojn pri DBMS-subteno, prefere ol krei komfortan disvolvan procezon.
Pros:
- Subtenas la necesan DBMS (inkluzive de Oracle)
Kons:
- Orakolo (same kiel Access, kiu estas negrava por ni) ne estas subtenata en .NET Core, nur en .NET Full Framework
- Ne funkcias kun ORM
- Estas eĉ malpli da dokumentaro ol la antaŭa ilo
- Denove - migradoj estas skribitaj per skriptoj
ThinkingHome.Migrator
Ilo por versionita datumbaza skemmigrado al la .NET Core-platformo, distribuita sub la MIT-licenco. .
Pros:
- Desegnita por .NET Kerno
- Efektivigis disbranĉigan sekvencon de migradoj
- Efektivigita migrado-registrado
Kons:
- Laste ĝisdatigita antaŭ jaro. Ŝajne la projekto ne estas subtenata
- Ne subtenata de Oracle (la artikolo diras, ke tio estas pro la manko de stabila efektivigo por .NET Core - sed ĉi tio estas antaŭ jaro)
- Neniu aŭtomata generacio de migradoj
Ĝenerale, la projekto aspektas promesplena, precipe se ĝi evoluus, sed ni devis fari decidon ĉi tie kaj nun.
Flua Migranto
La plej populara migra ilo kun granda armeo de adorantoj. Distribuite sub la permesilo Apache 2.0. Kiel dirite en la priskribo, ĝi estas migradkadro por .NET, simila al Ruby on Rails Migrations. Ŝanĝoj al la datumbaza skemo estas priskribitaj en C#-klasoj.
Estas avantaĝoj ĉi tie:
- Subteno por postulata DBMS
- .NET Kerna subteno
- Granda evoluinta komunumo
- Konfliktoj inter migradoj estas solvitaj sinsekve - la ordo de ekzekuto de migradoj estas precizigita. Krome, se konflikto ekestas ĉirkaŭ unu ento, dum kunfandado de la kodo, ĝi estas solvita en la sama maniero kiel en la resto de la kodo
- Estas profiloj, kiuj estas ekzekutitaj post sukcesa migrado. Kaj ili povas porti servofunkciojn.La lasta ĝisdatigo estis antaŭ monato, tio estas, la projekto vivas
Koncerne la minusojn, jen ili:
- Neniu aŭtomata generacio de migradoj
- Neniu rilato kun EF-modeloj
- Neniuj datumbazaj momentfotoj
Kio estis nia elekto?
La ekscititaj debatoj turnis ĉirkaŭ du parametroj - aŭtomata generacio de migradoj kaj prudenta solvado de konfliktoj. Aliaj faktoroj estis multe malpli timigaj. Kiel rezulto, surbaze de la rezultoj de la diskuto, la teamo decidis uzi Fluent Migrator en la nova projekto. Ĉar solvi konfliktojn en la estonteco alportos multe pli da avantaĝoj.
trovoj
Kompreneble, ne ekzistas perfektaj iloj. Do ni devis prioritatigi niajn "dezirojn" fari elekton. Tamen, por aliaj teamoj kaj aliaj taskoj, aliaj faktoroj povas esti decidaj. Ni esperas, ke ĉi tiu artikolo helpos vin fari elekton.
fonto: www.habr.com