Paragone è selezzione di sistemi di migrazione di dati
U mudellu di dati tende à cambià durante u prucessu di sviluppu, è in un certu puntu cessà di currisponde à a basa di dati. Di sicuru, a basa di dati pò esse sguassata, è dopu l'ORM creà una nova versione chì currisponde à u mudellu, ma sta prucedura porta à a perdita di dati esistenti. Cusì, a funzione di u sistema di migrazione hè di assicurà chì, in u risultatu di un cambiamentu di schema, hè sincronizatu cù u mudellu di dati in l'applicazione senza perde e dati esistenti.
In questu articulu, vulemu cunsiderà diversi strumenti per gestisce e migrazioni di basa di dati. Speremu chì sta rivista serà utile per i sviluppatori affruntati cù una scelta simili.
Objettivu
A nostra cumpagnia hè attualmente sviluppata attivamente a prossima generazione di u produttu - Docs Security Suite (DSS). A parte di u servitore hè scrittu in .Net Core, è l'Entity Framework Core hè utilizatu cum'è DBMS, rispettivamente. Quandu cuncepisce una applicazione, usemu l'approcciu Code First.
U mudellu di duminiu di l'applicazione hè creatu da parechji sviluppatori à u stessu tempu - ognunu hè rispunsevule per a so propria parte logica di u sistema.
A generazione precedente di DSS hà utilizatu u classicu Entity Framework Migrations (EF 6) cum'è sistema di gestione di migrazione. Tuttavia, certi lagnanza anu accumulatu contru à ellu, u principale di quale era chì EF ùn manca un accostu sanu per risolve i cunflitti di versione. Stu fattu ci disturba sempre quandu u bugfixing cum'è parte di u supportu, cusì hè statu decisu di cunsiderà opzioni alternative.
In u risultatu di a discussione, i seguenti requisiti per u sistema di gestione di migrazione sò stati furmati:
- Supportu per diversi DBMS. Ubligatoriu MS SQL Server, PostgreSQL, Oracle, ma hè potenzalmentu pussibule di utilizà altri
- U travagliu cù ORM Inizialmente, EF Core devia esse usatu, ma in u stadiu di cuncepimentu, altri ORM eranu pronti per esse cunsideratu.
- Generazione automatica di migrazioni. In vista di u sviluppu di Code First, mi piacerebbe evitari a necessità di migrazioni di "pittura cù penne".
- Cunflitti di versione. In un ambiente di sviluppu distribuitu, quandu si fusiona, EF Core pò cascà in cunflitti. Questu diventa un prublema significativu postu chì e diverse parti di l'applicazione sò create da diversi sviluppatori, cusì avete da passà assai tempu nantu à ognunu.
- Documentazione sviluppata è supportu. Quì, ci pari, ùn ci hè bisognu di spiegazione.
- Gratuitu. U criteriu hè cundizionale, postu chì ùn sò micca sistemi assai caru o caru, ma ideale in cunvenzione, eramu ancu pronti à cunsiderà
In u risultatu di un picculu studiu, e seguenti opzioni sò state trovate è cunsiderate desiderate per a considerazione:
- EF Core Migrations
- DBup
- Roundhouse E
- ThinkingHome.Migrator
- Migratore fluente
È avà un pocu di più
Naturalmente, questa era a prima è principale opzione per a scelta. Un strumentu nativu chì travaglia fora di a scatula senza nisun ballu di tamburinu. Una grande quantità di documentazione, ufficiale è micca cusì, simplicità, etc. Tuttavia, l'affirmazioni fatte contr'à l'EF classicu sò abbastanza pertinenti ancu per EF Core.
Cusì, i prufessori sò evidenziati per EF Core:
- Supportu Microsoft, documentazione, ancu in russo, una cumunità enormosa
- Autogenerazione di migrazioni basatu nantu à CodeFirst
- Comparatu à EF 6, EF Core ùn almacena più una snapshot di a basa di dati. L'implementazione di a basa di dati ùn hè più necessariu quandu travaglia cù EF Core in Code First
- Siccomu ballemu da Code First, hè pussibule di fà una migrazione à tutti i fornituri d'accessu à i dati
- In quantu à i fornituri, supporta PostgreSQL, Oracle, etc., etc., è ancu MS SQL Server
È ancu i contra:
- A risoluzione di u cunflittu resta a stessa. Hè necessariu di custruisce una sequenza di migrazioni è aghjurnà snapshots di basa di dati
- Dipendenza di mudelli basati nantu à quali migrazioni sò generati
DbUp
DbUp hè una biblioteca .NET chì hè stallata da NuGet è aiuta à spinghja i cambiamenti à SQL Server. Mantene a traccia di quali script di cambiamentu sò digià eseguiti è eseguisce quelli necessarii per aghjurnà a basa di dati. A biblioteca hè cresciuta da un prughjettu di u mutore di blogging open source in ASP.NET è esiste sottu a licenza MIT, è u codice hè in GitHub. E migrazioni sò descritte cù T-SQL.
Chì sò i vantaghji quì:
- Supportu per un gran numaru di DBMS (MS SQL Server, PstgreSQL, MySQL)
- Siccomu i scripts sò scritti in T-SQL, parevanu abbastanza simplici.
- I cunflitti sò ancu risolti cù SQL
E i contra:
- Cù tutta a varietà di DBMS supportati, Oracle ùn hè micca unu di elli
- Ùn interagisce micca cù ORM
- Scrivite scripts in T-SQL cù "manichi" ùn hè micca ciò chì avemu avutu
- A ducumentazione è a cumunità hè cusì cusì, ancu s'è in quantu à scrive script SQL, ùn anu micca bisognu.
Roundhouse E
Stu strumentu di gestione di migrazione, distribuitu sottu a licenza Apache 2.0, cum'è a precedente, funziona nantu à u mutore di migrazioni T-SQL. Apparentemente, i sviluppatori anu focu annantu à risolve i prublemi tecnichi in quantu à sustene u DBMS, invece di creà un prucessu di sviluppu còmode.
Pros:
- Supporta DBMS necessariu (cumpresu Oracle)
Cons:
- Oracle (cum'è Access, chì hè irrilevante per noi) ùn hè micca supportatu in .NET Core, solu in .NET Full Framework.
- Ùn funziona micca cù ORM
- Ancu menu documentazione chì l'utile precedente
- In novu - e migrazioni sò scritti da scripts
ThinkingHome.Migrator
Strumentu per a migrazione versionata di u schema di basa di dati à a piattaforma .NET Core, distribuitu sottu a licenza MIT. .
Pros:
- Adupratu per .NET Core
- Implementatu una sequenza di ramificazione di migrazioni
- Logging di migrazione implementatu
Cons:
- L'ultima aghjurnazione hè stata un annu fà. Apparentemente u prugettu ùn hè micca supportatu
- Ùn hè micca supportatu da Oracle (l'articulu dice chì questu hè dovutu à a mancanza di una implementazione stabile per .NET Core - ma questu hè un annu fà)
- Manca l'autogenerazione di migrazioni
In generale, u prugettu pari promettenti, soprattuttu s'ellu hà sviluppatu, ma avemu bisognu di piglià una decisione quì è avà.
Migratore fluente
L'uttellu di migrazione più populari cù una grande basa di fan. Distribuitu sottu a licenza Apache 2.0. Cum'è dichjaratu in a descrizzione, hè un framework di migrazione per .NET, simile à Ruby on Rails Migrations. I cambiamenti di schema di basa di dati sò descritti in classi C#.
Ci sò i vantaghji quì:
- Supportu per u DBMS necessariu
- Supportu .NET Core
- Grande cumunità sviluppata
- I cunflitti di migrazione sò risolti in sequenza - l'ordine di migrazione hè specificatu. Inoltre, se un cunflittu nasce intornu à una entità, quandu si fusiona u codice, hè risoltu in u listessu modu cum'è in u restu di u codice.
- Ci sò profili chì currenu dopu una migrazione successu. È ponu purtari funzioni di serviziu.L'ultima aghjurnazione era un mesi fà, vale à dì, u prughjettu vive
In quantu à i contra, allora quì:
- Manca l'autogenerazione di migrazioni
- Manca a cumunicazione cù mudelli EF
- Nisun snapshots db
Chì era a nostra scelta ?
U dibattitu più caldu girava intornu à dui parametri - autogenerazione di migrazioni è risoluzione sana di cunflittu. Altri fattori spaventavanu assai menu. In u risultatu, basatu annantu à i risultati di a discussione, a squadra hà decisu di utilizà Fluent Migrator in u novu prughjettu. Per a risoluzione di cunflitti in u futuru purterà un numeru assai più grande di plus.
scuperti
Di sicuru, ùn ci sò micca strumenti perfetti. Allora avemu avutu a priorità a nostra "Wishlist" per fà una scelta. In ogni casu, per altri squadre è altre attività, altri fattori ponu esse decisive. Speremu chì questu articulu vi aiuterà à fà a vostra scelta.
Source: www.habr.com