Comparació i selecció de sistemes de migració de dades
El model de dades tendeix a canviar durant el procés de desenvolupament, i en algun moment deixa de correspondre a la base de dades. Per descomptat, es pot suprimir la base de dades i, a continuació, l'ORM crearà una nova versió que coincidirà amb el model, però aquest procediment comportarà la pèrdua de les dades existents. Així, la funció del sistema de migració és garantir que, com a conseqüència d'un canvi d'esquema, es sincronitzi amb el model de dades de l'aplicació sense perdre les dades existents.
En aquest article, ens agradaria tenir en compte diverses eines per gestionar les migracions de bases de dades. Esperem que aquesta revisió sigui útil per als desenvolupadors que s'enfrontin a una elecció similar.
Tasca
Actualment, la nostra empresa està desenvolupant activament la propera generació del producte: Docs Security Suite (DSS). La part del servidor està escrita en .Net Core i l'Entity Framework Core s'utilitza com a DBMS, respectivament. Quan dissenyem una aplicació, utilitzem l'enfocament Code First.
El model de domini de l'aplicació el creen diversos desenvolupadors alhora: cadascun és responsable de la seva pròpia part lògica del sistema.
La generació anterior de DSS utilitzava el clàssic Entity Framework Migrations (EF 6) com a sistema de gestió de migracions. Tanmateix, s'han acumulat algunes queixes contra ell, la principal de les quals va ser que EF no té un enfocament sensat per resoldre els conflictes de versions. Aquest fet encara ens molesta a l'hora de corregir errors com a part del suport, per la qual cosa es va decidir considerar opcions alternatives.
Com a resultat de la discussió, es van formar els requisits següents per al sistema de gestió de migracions:
- Suport per a diversos DBMS. Obligatori MS SQL Server, PostgreSQL, Oracle, però potencialment és possible utilitzar-ne altres
- Treballant amb ORM Inicialment, s'havia d'utilitzar EF Core, però en l'etapa de disseny, altres ORM estaven preparats per ser considerats.
- Autogeneració de migracions. Tenint en compte el desenvolupament de Code First, m'agradaria evitar la necessitat de migracions de "pintar amb bolígrafs".
- Conflictes de versions. En un entorn de desenvolupament distribuït, quan es fusiona, EF Core pot caure en conflictes. Això es converteix en un problema important, ja que diferents parts de l'aplicació són creades per diferents desenvolupadors, de manera que heu de dedicar molt de temps a cadascuna.
- Documentació desenvolupada i suport. Aquí, ens sembla, no cal cap explicació.
- Gratuït. El criteri és condicional, ja que sistemes no molt cars ni cars, però ideals en comoditat, també estàvem disposats a considerar
Com a resultat d'un petit estudi, es van trobar les opcions següents i es van considerar desitjables per a la seva consideració:
- EF Core Migrations
- DBup
- Rotonda E
- ThinkingHome.Migrator
- Migrador fluid
I ara una mica més
Naturalment, aquesta va ser la primera i principal opció per triar. Un instrument autòcton que funciona fora de la caixa sense cap ball de tamborí. Una gran quantitat de documentació, oficial i no tant, senzillesa, etc. Tanmateix, les afirmacions fetes contra l'EF clàssic també són força rellevants per a EF Core.
Així, es destaquen els avantatges d'EF Core:
- Suport de Microsoft, documentació, inclòs en rus, una comunitat enorme
- Generació automàtica de migracions basades en CodeFirst
- En comparació amb EF 6, EF Core ja no emmagatzema una instantània de la base de dades. La implementació de la base de dades ja no és necessària quan es treballa amb EF Core a Code First
- Com que estem ballant des de Code First, és possible realitzar una migració a tots els proveïdors d'accés a les dades necessaris
- Pel que fa als proveïdors, és compatible amb PostgreSQL, Oracle, etc., etc., i fins i tot MS SQL Server
I també els contres:
- La resolució de conflictes segueix sent la mateixa. Cal crear una seqüència de migracions i actualitzar les instantànies de la base de dades
- Dependència dels models en funció dels quals es generen les migracions
DbUp
DbUp és una biblioteca .NET que NuGet instal·la i ajuda a impulsar els canvis a SQL Server. Fa un seguiment de quins scripts de canvi ja s'han executat i executa els necessaris per actualitzar la base de dades. La biblioteca va sorgir d'un projecte de motor de blocs de codi obert a ASP.NET i existeix sota la llicència MIT, i el codi es troba a GitHub. Les migracions es descriuen mitjançant T-SQL.
Quins són els avantatges aquí:
- Suport per a un gran nombre de DBMS (MS SQL Server, PstgreSQL, MySQL)
- Com que els scripts estan escrits en T-SQL, semblen bastant simples.
- Els conflictes també es resolen amb SQL
I els contres:
- Amb tota la varietat de SGBD compatibles, Oracle no és un d'ells
- No interactua amb ORM
- Escriure scripts en T-SQL amb "handles" no és el que ens esforcem
- La documentació i la comunitat ho són, tot i que pel que fa a l'escriptura d'scripts SQL, és possible que no siguin necessaris.
Rotonda E
Aquesta eina de gestió de migracions, distribuïda sota la llicència Apache 2.0, com l'anterior, s'executa amb el motor de migracions T-SQL. Pel que sembla, els desenvolupadors es van centrar a resoldre problemes tècnics en termes de suport al SGBD, en lloc de crear un procés de desenvolupament còmode.
Pros:
- Admet el SGBD requerit (inclòs Oracle)
Contres:
- Oracle (així com Access, que és irrellevant per a nosaltres) no és compatible amb .NET Core, només amb .NET Full Framework
- No funciona amb ORM
- Encara menys documentació que l'eina anterior
- De nou: les migracions s'escriuen mitjançant scripts
ThinkingHome.Migrator
Eina per a la migració versionada de l'esquema de la base de dades a la plataforma .NET Core, distribuïda sota la llicència MIT. .
Pros:
- Dissenyat per a .NET Core
- S'ha implementat una seqüència de ramificació de migracions
- Registre de migració implementat
Contres:
- La darrera actualització va ser fa un any. Pel que sembla, el projecte no té suport
- No és compatible amb Oracle (l'article diu que això es deu a la manca d'una implementació estable per a .NET Core, però això és fa un any)
- Falta la generació automàtica de migracions
En general, el projecte sembla prometedor, sobretot si es va desenvolupar, però havíem de prendre una decisió aquí i ara.
Migrador fluid
L'eina de migració més popular amb una gran base de fans. Distribuït sota la llicència Apache 2.0. Com s'indica a la descripció, és un marc de migració per a .NET, similar a Ruby on Rails Migrations. Els canvis en l'esquema de la base de dades es descriuen a les classes C#.
Aquí hi ha avantatges:
- Suport per al SGBD requerit
- Suport .NET Core
- Gran comunitat desenvolupada
- Els conflictes de migració es resolen seqüencialment: s'especifica l'ordre de migració. A més, si sorgeix un conflicte al voltant d'una entitat, en combinar el codi, es resol de la mateixa manera que a la resta del codi.
- Hi ha perfils que s'executen després d'una migració satisfactòria. I poden portar funcions de servei.La darrera actualització va ser fa un mes, és a dir, el projecte viu
Pel que fa als contres, aquí:
- Falta la generació automàtica de migracions
- Falta comunicació amb models EF
- No hi ha instantànies db
Quina va ser la nostra elecció?
El debat més candent va girar al voltant de dos paràmetres: la generació automàtica de migracions i la resolució sana de conflictes. Altres factors van espantar molt menys. Com a resultat, a partir dels resultats de la discussió, l'equip va decidir utilitzar Fluent Migrator en el nou projecte. Per a la resolució de conflictes en el futur aportarà un nombre molt més gran d'avantatges.
Troballes
Per descomptat, no hi ha eines perfectes. Així que vam haver de prioritzar la nostra "Llista de desitjos" per triar. Tanmateix, per a altres equips i altres tasques, altres factors poden ser determinants. Esperem que aquest article us ajudi a triar.
Font: www.habr.com