Tietojen siirtojärjestelmien vertailu ja valinta
Tietomallilla on taipumus muuttua kehitysprosessin aikana, eikä se jossain vaiheessa enää vastaa tietokantaa. Tietenkin tietokanta voidaan poistaa, ja sitten ORM luo uuden version, joka vastaa mallia, mutta tämä menettely johtaa olemassa olevien tietojen menettämiseen. Siirtojärjestelmän tehtävänä on siis varmistaa, että se synkronoituu skeeman muutoksen seurauksena sovelluksen tietomallin kanssa menettämättä olemassa olevaa dataa.
Tässä artikkelissa haluamme tarkastella erilaisia työkaluja tietokannan siirtojen hallintaan. Toivomme, että tämä arvostelu on hyödyllinen kehittäjille, jotka kohtaavat samanlaisen valinnan.
Tehtävä
Yrityksemme kehittää parhaillaan aktiivisesti seuraavan sukupolven tuotetta – Docs Security Suitea (DSS). Palvelinosa on kirjoitettu .Net Core -kielellä, ja Entity Framework Corea käytetään DBMS:nä. Sovelluksen suunnittelussa käytämme Code First -lähestymistapaa.
Sovellusaluemallin luovat useat kehittäjät samanaikaisesti - jokainen vastaa omasta järjestelmän loogisesta osastaan.
Edellinen DSS-sukupolvi käytti siirronhallintajärjestelmänä klassista Entity Framework Migrations (EF 6) -järjestelmää. Sitä vastaan on kuitenkin kertynyt valituksia, joista suurin on se, että EF:ltä puuttuu järkevä lähestymistapa versioristiriitojen ratkaisemiseen. Tämä tosiasia ärsyttää meitä edelleen, kun korjaamme virheitä osana tukea, joten päätimme harkita vaihtoehtoisia vaihtoehtoja.
Keskustelun tuloksena syntyi seuraavat vaatimukset migraation hallintajärjestelmälle:
- Tuki erilaisille DBMS-järjestelmille. MS SQL Server, PostgreSQL, Oracle vaaditaan, mutta mahdollisesti on mahdollista käyttää muitakin
- Työskentely ORM:n kanssa. Aluksi oli tarkoitus käyttää EF Corea, mutta suunnitteluvaiheessa olimme valmiita harkitsemaan muita ORM:eja.
- Siirtojen automaattinen luominen. Ottaen huomioon Code Firstin kehityksen, haluaisin välttää "käsin kirjoittamisen" siirrot
- Versioristiriidat. Hajautetussa kehitysympäristössä sulautuessaan EF Core voi kärsiä konflikteista. Tästä tulee merkittävä ongelma, koska sovelluksen eri osat ovat eri kehittäjien luomia, joten sinun on käytettävä paljon aikaa kuhunkin
- Edistynyt dokumentaatio ja tuki. Tässä ei meidän mielestämme tarvita selityksiä
- Vapaa. Kriteeri on ehdollinen, koska järjestelmät eivät ole kovin kalliita tai kalliita, mutta mukavuuden kannalta ihanteellisia, olimme myös valmiita harkitsemaan
Pienen tutkimuksen tuloksena löydettiin seuraavat vaihtoehdot, jotka katsottiin harkittaviksi:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Sujuva siirtolainen
Ja nyt vähän tarkemmin
Tämä oli luonnollisesti ensimmäinen ja tärkein vaihtoehto. Alkuperäinen instrumentti, joka toimii heti ilman tamburiinia. Suuri määrä dokumentaatiota, virallista ja ei niin, yksinkertaisuus jne. Klassisesta EF:stä tehdyt valitukset ovat kuitenkin varsin tärkeitä myös EF Corelle.
Näin ollen EF Coren edut korostetaan:
- Microsoftin tuki, dokumentaatio, myös venäjäksi, valtava yhteisö
- Siirtojen automaattinen luominen CodeFirstiin perustuen
- EF 6:een verrattuna EF Core ei enää tallenna tilannekuvaa tietokannasta. Kun työskentelet EF Coren kanssa Code Firstissä, tietokantaa ei enää tarvitse ottaa käyttöön
- Koska tanssimme Code Firstistä, on mahdollista suorittaa yksi migraatio kaikille vaadituille tiedonsaantipalveluntarjoajille
- Mitä tulee palveluntarjoajiin, PostgreSQL on tuettu, Oracle on tuettu jne. jne. ja jopa MS SQL Server
Ja myös haitat:
- Konfliktinratkaisu pysyi samalla tasolla. Siirrot on järjestettävä ja tietokannan tilannevedokset päivitettävä
- Riippuvuus malleista, joilla siirrot luodaan
DbUp
DbUp on NuGetin asentama .NET-kirjasto, joka auttaa tekemään muutoksia SQL Serveriin. Se seuraa, mitkä muutoskomentosarjat on jo suoritettu, ja suorittaa ne, jotka ovat tarpeen tietokannan päivittämiseksi. Kirjasto syntyi avoimen lähdekoodin blogimoottorin projektista ASP.NETissä ja on olemassa MIT-lisenssillä, ja koodi on GitHubissa. Siirrot kuvataan T-SQL:llä.
Mitkä ovat edut:
- Tuki suurelle määrälle tietokantajärjestelmiä (MS SQL Server, PstgreSQL, MySQL)
- Koska komentosarjat on kirjoitettu T-SQL:llä, ne näyttävät melko yksinkertaisilta
- Myös ristiriidat ratkaistaan SQL:n avulla
Ja miinukset:
- Kaiken tuettujen DBMS-järjestelmien ansiosta Oracle ei ole yksi niistä
- Ei ole vuorovaikutuksessa ORM:n kanssa
- T-SQL-skriptien kirjoittaminen käsin ei ole sitä, mihin pyrimme
- Dokumentaatio ja yhteisö ovat niin ja niin, vaikka SQL-skriptien kirjoittamisen kannalta ne eivät välttämättä ole tarpeellisia.
RoundhouseE
Tämä Apache 2.0 -lisenssillä jaettu muuton hallintatyökalu, kuten edellinen, toimii T-SQL-siirtomoottorilla. Ilmeisesti kehittäjät asettivat etusijalle DBMS-tukeen liittyvien teknisten ongelmien ratkaisemisen mukavan kehitysprosessin luomisen sijaan.
Plussat:
- Tukee tarvittavaa DBMS-järjestelmää (mukaan lukien Oracle)
Miinukset:
- Oracle (sekä Access, joka ei ole meille merkityksellinen) ei tue .NET Corea, vain .NET Full Framework
- Ei toimi ORM:n kanssa
- Dokumentaatiota on vielä vähemmän kuin edellinen työkalu
- Jälleen – siirrot kirjoitetaan skripteillä
ThinkingHome.Migrator
Työkalu versioidun tietokantaskeeman siirtämiseen .NET Core -alustalle, jaettu MIT-lisenssillä. .
Plussat:
- Suunniteltu .NET Corelle
- Toteutettu haaroittuva siirtymäsarja
- Toteutettu siirtoloki
Miinukset:
- Päivitetty viimeksi vuosi sitten. Ilmeisesti hanketta ei tueta
- Oracle ei tue (artikkelissa sanotaan, että tämä johtuu .NET Coren vakaan toteutuksen puutteesta - mutta tämä on vuosi sitten)
- Ei automaattista siirtymien luomista
Kaiken kaikkiaan projekti näyttää lupaavalta, varsinkin jos se kehittyy, mutta meidän piti tehdä päätös tässä ja nyt.
Sujuva siirtolainen
Suosituin siirtotyökalu suurella fanijoukolla. Jaettu Apache 2.0 -lisenssillä. Kuten kuvauksessa todetaan, se on .NET:n siirtokehys, joka on samanlainen kuin Ruby on Rails Migrations. Muutokset tietokantaskeemaan kuvataan C#-luokissa.
Tässä on etuja:
- Tuki vaaditulle DBMS:lle
- .NET Core -tuki
- Suuri kehittynyt yhteisö
- Siirtojen väliset ristiriidat ratkaistaan peräkkäin – siirtojen suoritusjärjestys on määritetty. Lisäksi jos yhden entiteetin ympärillä syntyy ristiriita, koodia yhdistettäessä se ratkaistaan samalla tavalla kuin muualla koodissa
- On profiileja, jotka suoritetaan onnistuneen siirron jälkeen. Ja ne pystyvät kantamaan palvelutoimintoja Viimeisin päivitys oli kuukausi sitten, eli projekti on elossa
Mitä tulee miinuksiin, tässä ne ovat:
- Ei automaattista siirtymien luomista
- Ei yhteyttä EF-malleihin
- Ei tietokannan tilannekuvia
Mikä oli valintamme?
Kiivaat keskustelut pyörivät kahden parametrin ympärillä - automaattisen muuttoliikkeen luomisen ja järkevän konfliktien ratkaisemisen. Muut tekijät olivat paljon vähemmän pelottavia. Tämän seurauksena ryhmä päätti keskustelun tulosten perusteella käyttää Fluent Migratoria uudessa projektissa. Koska konfliktien ratkaiseminen tulevaisuudessa tuo paljon enemmän hyötyä.
Tulokset
Täydellisiä työkaluja ei tietenkään ole olemassa. Joten meidän oli priorisoitava "halumme" tehdäksemme valinnan. Muiden ryhmien ja muiden tehtävien kannalta muut tekijät voivat kuitenkin olla ratkaisevia. Toivomme, että tämä artikkeli auttaa sinua tekemään valinnan.
Lähde: will.com