Сравнение и избор на системи за миграция на данни

Сравнение и избор на системи за миграция на данни

Моделът на данните има тенденция да се променя по време на процеса на разработка и в даден момент престава да съответства на базата данни. Разбира се, базата данни може да бъде изтрита и след това ORM ще създаде нова версия, която ще съответства на модела, но тази процедура ще доведе до загуба на съществуващи данни. По този начин функцията на системата за миграция е да гарантира, че в резултат на промяна на схемата тя се синхронизира с модела на данни в приложението, без да се губят съществуващи данни.

В тази статия бихме искали да разгледаме различни инструменти за управление на миграции на бази данни. Надяваме се, че този преглед ще бъде полезен за разработчици, изправени пред подобен избор.

Задача

В момента нашата компания активно разработва следващото поколение на продукта - Docs Security Suite (DSS). Сървърната част е написана на .Net Core, а Entity Framework Core се използва съответно като СУБД. Когато проектираме приложение, ние използваме подхода Code First.

Моделът на домейна на приложението се създава от няколко разработчици едновременно - всеки отговаря за собствената си логическа част на системата.

Предишното поколение на DSS използва класическите Entity Framework Migrations (EF 6) като система за управление на миграцията. Въпреки това срещу него се натрупаха някои оплаквания, основното от които беше, че на EF липсва разумен подход за разрешаване на конфликти на версии. Този факт все още ни разстройва, когато коригираме грешки като част от поддръжката, така че беше решено да разгледаме алтернативни опции.

В резултат на дискусията бяха формирани следните изисквания към системата за управление на миграцията:

1. Поддръжка на различни СУБД. Задължително MS SQL Server, PostgreSQL, Oracle, но е потенциално възможно да се използват и други
2. Работа с ORM Първоначално трябваше да се използва EF Core, но на етапа на проектиране други ORM бяха готови да бъдат разгледани
3. Автоматично генериране на миграции. Като се има предвид развитието на Code First, бих искал да избегна необходимостта от миграции „рисуване с химикалки“.
4. Конфликти на версиите. В разпределена среда за разработка, при сливане, EF Core може да попадне в конфликти. Това се превръща в сериозен проблем, тъй като различните части на приложението са създадени от различни разработчици, така че трябва да отделите много време за всяка
5. Разработена документация и поддръжка. Тук, струва ни се, не е необходимо обяснение.
6. Безплатно. Критерият е условен, тъй като не много скъпи системи или скъпи, но идеални като удобство, също бяхме готови да разгледаме

В резултат на малко проучване бяха открити следните опции, които бяха счетени за желателни за разглеждане:

1. Миграции на EF Core
2. DBup
3. Кръгла къщаE
4. ThinkingHome.Migrator
5. Fluent Migrator

А сега още малко

Основни миграции на EntityFramework

Естествено това беше първият и основен вариант за избор. Роден инструмент, който работи от кутията без никакви танци на тамбура. Голямо количество документация, официална и не толкова, простотия и т.н. Въпреки това твърденията срещу класическия EF са доста подходящи и за EF Core.

По този начин плюсовете са подчертани за EF Core:

• Поддръжка на Microsoft, документация, включително на руски, огромна общност
• Автоматично генериране на миграции на базата на CodeFirst
• В сравнение с EF 6, EF Core вече не съхранява моментна снимка на базата данни. Разполагането на базата данни вече не е необходимо, когато работите с EF Core в Code First
• Тъй като танцуваме от Code First, е възможно да извършим една миграция към всички необходими доставчици на достъп до данни
• Що се отнася до доставчиците, той поддържа PostgreSQL, Oracle и т.н. и т.н. и дори MS SQL Server 

И също минуси:

• Разрешаването на конфликти остава същото. Необходимо е да се изгради последователност от миграции и да се актуализират моментните снимки на базата данни
• Зависимост от модели, въз основа на които се генерират миграции

DbUp

dbup.github.io

DbUp е .NET библиотека, която се инсталира от NuGet и помага за натискане на промени в SQL Server. Той следи кои скриптове за промяна вече са били изпълнени и изпълнява тези, необходими за актуализиране на базата данни. Библиотеката е израснала от проект на машина за блогове с отворен код на ASP.NET и съществува под лиценза на MIT, а кодът е в GitHub. Миграциите са описани с помощта на T-SQL.

Какви са предимствата тук:

• Поддръжка на голям брой СУБД (MS SQL Server, PstgreSQL, MySQL)
• Тъй като скриптовете са написани на T-SQL, те изглеждат доста прости.
• Конфликтите също се разрешават със SQL

И минусите:

• С цялото разнообразие от поддържани СУБД, Oracle не е една от тях
• Не взаимодейства с ORM
• Писането на скриптове в T-SQL с „ръкохватки“ не е това, към което се стремихме
• Документацията и общността са така-така, въпреки че по отношение на писането на SQL скриптове може да не са необходими.

Кръгла къщаE

github.com/chucknorris/roundhouse

Този инструмент за управление на миграцията, разпространяван под лиценза Apache 2.0, подобно на предишния, работи на машината за миграции на T-SQL. Очевидно разработчиците са се фокусирали върху решаването на технически проблеми по отношение на поддръжката на СУБД, а не върху създаването на удобен процес на разработка.

плюсове:

• Поддържа необходимата СУБД (включително Oracle)

против:

• Oracle (както и Access, който е без значение за нас) не се поддържа от .NET Core, а само от .NET Full Framework
• Не работи с ORM
• Още по-малко документация от предишния инструмент
• Отново - миграциите се пишат със скриптове

ThinkingHome.Migrator

Инструмент за версионна миграция на схемата на базата данни към платформата .NET Core, разпространявана под лиценза на MIT. Самият разработчик писа за последната му версия преди почти година.

плюсове:

• Създаден за .NET Core
• Реализира разклонена последователност от миграции
• Внедрено регистриране на миграцията

против:

• Последната актуализация беше преди година. Очевидно проектът не се поддържа
• Не се поддържа от Oracle (в статията се посочва, че това се дължи на липсата на стабилна реализация за .NET Core - но това е преди година)
• Липсва автоматично генериране на миграции

Като цяло проектът изглежда обещаващ, особено ако се развие, но трябваше да вземем решение тук и сега.

Fluent Migrator

github.com/fluentmigrator/fluentmigrator

Най-популярният инструмент за миграция с голяма база от фенове. Разпространява се под лиценз Apache 2.0. Както е посочено в описанието, това е миграционна рамка за .NET, подобна на Ruby on Rails Migrations. Промените в схемата на базата данни са описани в C# класове.

Тук има плюсове:

• Поддръжка на необходимата СУБД
• Поддръжка на .NET Core
• Голяма развита общност
• Миграционните конфликти се разрешават последователно - посочва се редът на миграция. Освен това, ако възникне конфликт около един обект, при обединяването на кода той се разрешава по същия начин, както в останалата част от кода.
• Има профили, които се изпълняват след успешна миграция. И те могат да носят сервизни функции.Последната актуализация беше преди месец, тоест проектът живее

Що се отнася до минусите, тогава тук:

• Липсва автоматично генериране на миграции
• Липсва комуникация с EF моделите
• Няма db моментни снимки

Какъв беше нашият избор?

Най-горещият дебат се въртеше около два параметъра - автоматично генериране на миграции и разумно разрешаване на конфликти. Други фактори плашеха много по-малко. В резултат на това, въз основа на резултатите от дискусията, екипът реши да използва Fluent Migrator в новия проект. За разрешаването на конфликти в бъдеще ще донесе много по-голям брой плюсове.

Данни

Разбира се, няма идеални инструменти. Така че трябваше да дадем приоритет на нашия „списък с желания“, за да направим избор. Въпреки това, за други екипи и други задачи други фактори могат да бъдат решаващи. Надяваме се, че тази статия ще ви помогне да направите своя избор.

Източник: www.habr.com