Вопрос по automation, ef-model-first, entity-framework-4.1, ef-migrations, database – Миграция с использованием модели первого подхода в рамках сущности

14

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

  1. Use the Generate database from model feature of entity framework. I create a dummy database and apply those scripts. which deletes all my data and tables first and then updates the database with the latest sql file which is generated by entity framework.
  2. Now I use the Visual Studio's schema compare feature and generate migration scripts for my local database and also for the one which is in production.
  3. I go through the scripts manually and verify them. Once that is done I run the migration scripts on the production instances.

Question : Основная проблема в том, что это действительно утомительно, и, поскольку я делаю это из своей локальной системы, подключение к базам данных Prod происходит очень медленно, и иногда моя визуальная студия также падает. Есть ли более чистый подход к этому? Какой из них более автоматизирован, так что мой ноутбук на самом деле не отвечает за миграцию базы данных на производственных экземплярах?

Очень умный способ использования схемы VS для сравнения процедуры гораздо лучше, чем выполнение команд создания и удаления таблицы вручную. kevin
Мы делаем то же самое: сначала модель, генерируем БД из модели, затем связываем sql в проекте БД, который сравнивает сценарий с производственной БД (что мы делаем для локального резервного копирования по скорости). Я согласен, что этот процесс немного утомителен и мы также рассматриваем то, что мы делаем, переходя на EF6 и т. д. Альтернатива написанию этого кода мне сначала кажется немного более утомительной? По крайней мере, при сравнении с базой данных можно получить сценарий о фактической разнице за один раз, а не о том, что кто-то пропустил некоторые сценарии миграции, возможно, проще для одного человека сделать / исправить, но это еще один шаг? Хороший вопрос! Mark Redman

Ваш Ответ

2   ответа
5

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

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

спасибо, Ладислав. Я использую это в настоящее время. Но это все равно потребует от меня запуска скрипта с моего ноутбука. Что я действительно не хочу. Tushar
Поэтому вам следует пересмотреть вопрос о преобразовании своего проекта вначале с помощью миграций (и всех их плюсов и минусов), потому что модель сначала не предлагает лучшего способа - любой подход всегда приводит к сценарию SQL, который вы должны выполнить вручную или вы должны включить это выполнение напрямую. к вашему заявлению.
Кто-нибудь знает, будет ли EF поддерживать Миграции, созданные из Модели в будущем?
3

очень похожий на продукт RedGate, возможно, немного дешевле) -a good 3rd party tool is much easier to use than a VS Database Project и его легко применять с помощью инструмента-скрипта, такого как RoundHousE.

Использование его в подходе Model First может следовать подходу Schema First с использованием цикла Model & # x2011; Schema & Diff & # x2011; Schema & # x2011; Model, как описано в посте; рассмотрите эти руководящие принципы / примечания ниже для упрощенного процесса.The schema-diff approach does not need to be tedious, slow, or excessively manual.

The current version of the database schema is obtained by applying a sequence of database patches (or DDL/DML scripts).

A tool (we use RoundHousE) automatically applies the scripts, as needed. It records information to know which scripts have been applied. Applying the same scripts is idempotent.

Diff done against a local database; this local database can be built up from all the previous change scripts in an automated fashion. This latest-local is always the diff target for the latest model changes.

The remote/live database is never used as a diff target. The same scripts can be applied later to the test (and then live) databases. Since everything is done the same way then the process is repeatable on all databases.

The only "issue" is that an update that is not well thought out may lead to data that is invalid under new restrictions/constraints. Of course, this was easy to identify, fix, and re-diff before pushing to the live database.

Once a diff is committed to source control it must be applied on the branch. To "undo" a previously commit change-script requires creating a new diff applying an inverse action. There is no implicit down-version.

We have a [Hg] model branch that affectively acts as a schema lock that that must be unified against; this could be viewed as a weak point, but it has worked well with small-team development.

A tool like Huagati DBML/EDMX is used to synchronize the Schema back to the Model which is really useful when developing. This little gem really pays for itself and is part of the cycle. When this is employed it's easy to also "update to a model" or make Schema changes in SSMS (or whatever) and then bring them back over.

Миграции Code First "OK" (и определенно лучше, чем ничто!), но яonly их использование, потому что Azure SQL (он же база данных SQL) не поддерживается расширенными инструментами сравнения из-за отсутствия раскрытия различной системной информации. (Различия могут выполняться локально, как обычно, но ApexSQL Diff генерирует DDL / DML, который не всегда дружит с Azure SQL - плюс, для меня это шанс изучить немного другой подход :-)

Некоторые преимущества миграций Code First через Power Pack: можно выполнять задачи обновления в C # вместо ограничения DDL / DML (может быть удобно), автоматического понижения версии (хотя я сомневаюсь в их использовании), не нужно покупать стороннюю версию инструмент (может быть дорогим), более простая интеграция / развертывание в Azure SQL, меньшая привязка к конкретному поставщику базы данных (теоретически) и т. д.

Хотя миграция Code First (и ее автоматизация) является хорошим шагом вперед по сравнению сabsolutely horrid Подход Drop-and-Recreate, я очень предпочитаю выделять инструменты SQL при разработке.

Похожие вопросы