Сравнение и выбор систем миграции данных
Модель данных имеет свойство меняться в процессе разработки и в какой-то момент перестает соответствовать базе данных.
Конечно, базу данных можно удалить, и тогда ORM создаст новую версию, которая будет соответствовать модели, но эта процедура приведет к потере существующих данных.
Таким образом, функция системы миграции заключается в том, чтобы в результате изменения схемы она синхронизировалась с моделью данных в приложении без потери существующих данных.
В этой статье мы хотели бы рассмотреть различные инструменты для управления миграцией баз данных.
Надеемся, этот обзор будет полезен разработчикам, оказавшимся перед подобным выбором.
Задача
Наша компания в настоящее время активно разрабатывает продукт следующего поколения — Docs Security Suite (DSS).Серверная часть написана на .
Net Core, а в качестве СУБД используется Entity Framework Core. При разработке приложения мы используем подход Code First. Модель предметной области приложения создается одновременно несколькими разработчиками — каждый отвечает за свою логическую часть системы.
Предыдущее поколение DSS использовало классическую Entity Framework Migrations (EF 6) в качестве системы управления миграцией.
Однако к нему накопились некоторые нарекания, главная из которых — отсутствие у EF вменяемого подхода к разрешению конфликтов версий.
Этот факт до сих пор расстраивает нас при исправлении ошибок в рамках поддержки, поэтому мы решили рассмотреть альтернативные варианты.
В результате обсуждения были сформированы следующие требования к системе управления миграцией:
- Поддержка различных СУБД.
Требуется MS SQL Server, PostgreSQL, Oracle, но потенциально возможно использование и других.
- Работаем с ОРМ.
Изначально планировалось использовать EF Core, но на этапе проектирования мы были готовы рассмотреть и другие ORM.
- Автогенерация миграций.
Учитывая развитие Code First, хотелось бы избежать необходимости «писать» миграции вручную.
- Конфликты версий.
В распределенной среде разработки при слиянии EF Core может столкнуться с конфликтами.
Это становится существенной проблемой, поскольку разные части приложения создаются разными разработчиками, поэтому на каждую приходится тратить много времени.
- Расширенная документация и поддержка.
Здесь, нам кажется, пояснения не нужны.
- Бесплатно.
Критерий условный, так как системы не очень дорогие и дорогие, но идеальные по удобству, мы тоже готовы были рассмотреть
- Основные миграции EF
- ДБуп
- РаундхаусE
- ДумаяДомой.
Мигратор
- Свободный мигратор
А теперь немного подробнее
Основные миграции EntityFramework Естественно, это был первый и основной вариант выбора.
Родной инструмент, работающий из коробки без всяких возни с бубном.
Большой объем документации, официальная и не очень, простота и т.д. Впрочем, претензии к классическому EF вполне актуальны и для EF Core. Таким образом, выделены преимущества EF Core:
- Поддержка Microsoft, документация, в том числе на русском языке, огромное сообщество.
- Автогенерация миграций на основе CodeFirst
- По сравнению с EF 6, EF Core больше не хранит моментальный снимок базы данных.
При работе с EF Core в Code First больше не требуется развертывание базы данных.
- Поскольку мы танцуем от Code First, то можно провести одну миграцию ко всем необходимым провайдерам доступа к данным.
- Что касается провайдеров, то поддерживается PostgreSQL, поддерживается Oracle и т.д. и т.п.
и даже MS SQL Server
- Разрешение конфликтов осталось на прежнем уровне.
Необходимо упорядочить миграцию и обновить снимки базы данных.
- Зависимость от моделей, на которых генерируются миграции
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-скриптов они могут и не понадобиться.
github.com/chucknorris/roundhouse Этот инструмент управления миграцией, распространяемый по лицензии Apache 2.0, как и предыдущий, работает на механизме миграции T-SQL. Судя по всему, разработчики поставили на первое место решение технических проблем по поддержке СУБД, а не создание комфортного процесса разработки.
Плюсы:
- Поддерживает необходимые СУБД (в том числе Oracle)
- Oracle (как и Access, который для нас неактуален) не поддерживается на .
NET Core, только на .
NET Full Framework.
- Не работает с ОРМ
- Документации еще меньше, чем у предыдущего инструмента.
- Опять же — миграции пишутся скриптами
Мигратор 
Инструмент для миграции схемы версионной базы данных на платформу .
NET Core, распространяемый по лицензии MIT. О ее последней версии сам разработчик написал почти год назад. .
Плюсы:
- Разработан для .
NET Core.
- Реализована ветвящаяся последовательность миграций.
- Реализовано ведение журнала миграции.
- Последнее обновление год назад. Судя по всему проект не поддерживается
- Не поддерживается Oracle (в статье указано, что это связано с отсутствием стабильной реализации для .
NET Core — но это было год назад)
- Нет автоматического создания миграций
Свободный мигратор 
github.com/fluentmigrator/fluentmigrator
Самый популярный инструмент миграции с большой армией поклонников.
Распространяется по лицензии Apache 2.0. Как указано в описании, это платформа миграции для .
NET, похожая на Ruby on Rails Migrations. Изменения в схеме базы данных описаны в классах C#.
Здесь есть свои преимущества:
- Поддержка необходимых СУБД
- Поддержка .
NET Core
- Большое развитое сообщество
- Конфликты между миграциями решаются последовательно — указывается порядок выполнения миграций.
Кроме того, если вокруг одной сущности возникает конфликт, то при слиянии кода он разрешается так же, как и в остальном коде.
- Есть профили, которые выполняются после успешной миграции.
И они могут нести сервисные функции.
Последнее обновление было месяц назад, то есть проект жив
- Нет автоматического создания миграций
- Нет связи с моделями EF
- Нет снимков базы данных
Каким был наш выбор?
Жаркие споры вращались вокруг двух параметров — автоматической генерации миграций и разумного разрешения конфликтов.
Другие факторы были гораздо менее пугающими.
В итоге по итогам обсуждения команда решила использовать Fluent Migrator в новом проекте.
Потому что разрешение конфликтов в будущем принесет гораздо больше пользы.
выводы
Конечно, идеальных инструментов не бывает. Поэтому нам пришлось расставить приоритеты в своих «желаниях», чтобы сделать выбор.Однако для других команд и других задач решающими могут оказаться иные факторы.
Надеемся, эта статья поможет вам сделать выбор.
Теги: #Управление разработкой #Хранение данных #базы данных #.
NET #.
net core #миграция баз данных
-
Электронные Коммутационные Системы
19 Oct, 24 -
Как Работает Отбеливание Зубов?
19 Oct, 24 -
Немного О Сборке Мусора И Генерациях
19 Oct, 24 -
Как Мы Делали Алкосканер
19 Oct, 24 -
Что Это За Продажа Автомобиля?
19 Oct, 24
