Объяснение Миграторов (FluentMigrator)?

здесь много вопросов. Я отвечу на вопросы с акцентом на FluentMigrator.

Это способ изначально создать, а затем поддерживать обновления для базы данных по способу управления версиями.

FluentMigrator-это способ управления версиями схемы базы данных. Все так или иначе это делают. Либо вручную, с помощью сценариев sql, с помощью такого инструмента, как SqlCompare или проект базы данных Visual Studio. Все эти методы легко испортить. Это так легко сделать ошибка при выпуске новой версии и привести к сбою системы. Миграция-лучший способ справиться с этим.

FluentMigrator позволяет определить изменение схемы как код, и это обычно регистрируется в вашей системе управления версиями с другими изменениями кода. Это означает, что вы можете сказать версию 1.XX вашей системы должна иметь версию 123 базы данных. Это означает, что если вы откатите свой код до предыдущей версии, вы также знаете, какую версию базы данных откатить как что ж.

его можно использовать как для создания схемы базы данных с самого начала, так и для запуска с управлением версиями схемы для существующей базы данных.

миграция-это способ описания изменения схемы базы данных. FluentMigrator создает таблицу VersionInfo и сохраняет уникальный идентификатор (номер версии) миграции после применения is.

например, если у меня есть две миграции один с Id 1 и один с Id 2. Если тогда я выполню первый Миграция затем Id 1 будет сохранен в таблице VersionInfo, и я могу посмотреть там и знать, что версия базы данных 1 и что версия 2 еще не применена.

возможность узнать, какая версия схемы базы данных очень полезна при переносе изменений из теста в производство или при наличии нескольких копий базы данных в производстве. Например, у меня есть клиент с офисами по всему миру и каждое отделение имеет свою собственную копию базы данных и все они на разных версиях. Без знания версии базы данных было бы очень сложно безопасно обновить их.

большую часть времени мне не нужно смотреть в таблице VersionInfo, FluentMigrator обрабатывает это автоматически. Он сравнивает сборку с миграциями в таблицу VersionInfo и выясняет, какие изменения еще не были применены, а затем выполняет их.

первая миграция (или начальная версия базы данных) будет содержать все необходимые таблицы, отношения и свойства (сделано либо свободно или с использованием куска sql в скрипте).

отправная точка зависит от вас. Можно выполнить первую миграцию, которая представляет собой сценарий sql, созданный из текущей базы данных. Вы также можете использовать один из проектов contrib, таких как FluentMigrator.Т4 для создания быстрой миграции. Или вы можете просто решить, что существующая база данных является отправной точкой и сохранить копию он сможет восстановить его как версию 1.

Я представил FluentMigrator для многих устаревших баз данных без каких-либо серьезных проблем.

Если вы хотите внести изменения в базу данных, вы создадите новую метод миграции (вверх и вниз), что-то вроде добавления новой таблицы или изменить поле.

да, Up используется для применения изменения, указанного в миграции, и Down откатывает его. Так может быть создать таблицу и вниз может быть опустите стол.

чтобы развернуть одну из этих миграций, вы должны использовать командную строку указание библиотеки dll, содержащей миграцию, строку подключения и требуемая версия.

три бегунки доступно для выполнения миграций. Бегун командной строки, задача Nant и задача MSBuild. Обычно они выполняются как часть сценария сборки.

класс MigrationRunner также может использоваться в коде. Вы это можно сделать, если вы хотите создать свой собственный runner или если у вас есть другие потребности (например, создание баз данных динамически или автоматическое обновление базы данных при добавлении новой миграции.)

Если бы у вас был довольно сложный набор моделей данных, не было бы скорее трудное и трудоемкое создание определения миграции для всех этого?

Я в основном уже ответил на это. Обычно довольно легко создать SQL-скрипт для базы данных. Для Sql Server создание сценария даже для больших баз данных занимает менее минуты. Этот скрипт можно сохранить в a .sql-файл и выполняется как первая миграция с помощью Execute.Выражение EmbeddedSqlScript. Это работает удовольствие.

Я знаю, что с nHibernate / fluent вы можете легко создавать таблицы для база данных без необходимости определять что-либо, кроме моделей и файл карты. Есть ли способ сделать эту конфигурацию совместимой с этот Мигратор / Управление Версиями?

на данный момент такой интеграции нет, и на практике я, по крайней мере, не упускаю ее. Была некоторая дискуссия о подключении Fluent NHibernate и FluentMigrator, но это будет много работы. Это позволит scaffolding генерировать изменения в модели, как это делают первые миграции кода EF. Однако на данный момент этого нет в дорожной карте.

когда nhibernate / fluent отвечает за создание базы данных, я не обязательно нужно определить каждый аспект таблицы. Его сделали либо через соглашение, либо через картографические файлы. С мигрантами I нужно ли будет определить этот уровень детализации?

да, вам нужно будет определить на этом уровне детализации. Миграции FluentMigrators-это DSL (собственный маленький язык) для определения изменений схемы, переведенных на sql. Вы можете написать sql напрямую, а также с помощью Execute.выражение SQL. Миграции Entity Framework имеют такой вид интеграции, которая имеет как преимущества, так и недостатки.

Проверьте wiki или один из учебников здесь, здесь (часть 1) или здесь (часть 2) для получения дополнительной помощи.