Развертывание версий базы данных. Миграции Entity Framework и SSDT DacPac

У меня есть приложение, ориентированное на данные, с SQL Server. Среды, в которых он будет развернут, не находятся под нашим контролем, и там нет администраторов баз данных (все это малые предприятия), поэтому нам нужно, чтобы процесс распространения каждого обновления приложения/базы данных был как можно более автоматическим.

Помимо обычных изменений между версиями приложения (иногда непредсказуемых), мы уже знаем, что нам нужно будет распространять некоторые новые начальные данные с каждой версией. Иногда эти исходные данные будут связаны с другими данными в нашей системе. Например: возможно, нам нужно будет вставить 2 новые строки некоторых основных данных в процессе обновления v2-v3 и еще 5 строк во время процесса обновления v5-v6.

EF

Мы проверили Entity Framework Db Migrations (доступно для существующих баз данных без Code-First начиная с выпуска 4.3.1), которые представляют традиционные последовательные сценарии более автоматическим и контролируемым способом (например, Fluent Migrations).

SSDT

С другой стороны, придерживаясь другой философии, мы проверили SSDT и его dacpacs, моментальные снимки и сценарии до и после развертывания.

Вопросы:

  1. Какая из этих технологий/философий больше подходит для описанного случая?

  2. Любая другая технология/философия, которую можно было бы использовать?

  3. Любой другой совет?

Заранее спасибо.


sql-server-2012 database-migration fluent-migrator data-tier-applications entity-framework-4.3
person Gustavo    schedule 24.04.2012    source источник
comment
Лучшее, что я видел, это ready-roll.com.   -  person Tim Abell    schedule 29.01.2016
comment
связанный programmers.stackexchange.com/questions/209815/   -  person Tim Abell    schedule 29.01.2016

Ответы (2)


arrow_upward
3
arrow_downward

Это интересный вопрос. Здесь, в Red Gate, мы надеемся решить эту проблему в конце этого года, так как многие клиенты спрашивают, как мы могли бы предоставить простой пакет развертывания. У нас есть SQL Packager, который, по сути, является оберткой для SQL-скрипта. в экзешник.

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

Раньше я не пробовал обновлять данные с помощью dacpacs, поэтому мне было бы интересно узнать, насколько хорошо это работает. Насколько я помню, он усекает целевые таблицы и заполняет их заново.

У меня нет опыта миграции EF, поэтому мне было бы любопытно прочитать любые ответы на эту тему.

person David Atkinson    schedule 26.04.2012
comment
-1 Вы не ответили на вопрос (нет опыта миграции EF, нет опыта обновления базы данных с помощью dacpacs), но определенно рекламировали свой продукт. - person Loki Kriasus; 24.08.2012
comment
Мне жаль, что вы так себя чувствуете, и я склонен не согласиться с вами. Гас задал три вопроса, а я ответил на второй: Любая другая технология/философия? Да, я упомянул продукт, за который несу ответственность, что, конечно же, не противоречит правилам. Хотя я не использовал их в гневе, я протестировал дакпаки и понял их ограничения. Да, мой практический опыт миграции EF ограничен, поэтому я и заявил об этом. - person David Atkinson; 27.08.2012
comment
Мне жаль. Я был недостаточно наблюдателен, и вы правы. Я хотел бы удалить отрицательный голос, но не могу, пока ответ не будет отредактирован. Пожалуйста извините меня :) - person Loki Kriasus; 28.08.2012

arrow_upward
1
arrow_downward

Вероятно, мы примем гибридное решение. Мы хотели бы не отказываться от идеи упаковщиков развертывания, но, с другой стороны, из-за характера наших приложений (малые предприятия в качестве конечных пользователей, без администраторов баз данных, без обязательств по обновлению, так что несколько «живых» версий базы данных сосуществуют), мы также не можем отказаться от полного контроля над процессом миграции, включая схему и данные. В нашем случае сценариев до и после развертывания может быть недостаточно (или, по крайней мере, недостаточно удобно) для полноценной миграции, как это делают EF Migrations. Такие изменения, как добавление/удаление начальных данных, изменение отношения «один ко многим» на отношение «многие ко многим» или даже радикальные изменения схемы базы данных (и, следовательно, миграция данных в эту схему из любой ранее выпущенной схемы) могут быть частью нашей дневник работы, когда наша первая версия выпущена.

Поэтому мы, вероятно, будем использовать миграции EF с его системой «вверх» и «вниз» для каждого выпуска версии. В принципе, каждый «Вверх» будет вызывать dacpac с последним снимком базы данных (а каждый «Вниз» — своим предыдущим), каждый со своими параметрами развертывания для этой конкретной миграции. Миграции EF будут обрабатывать строку управления версиями и, возможно, также некоторые сложные части миграции данных.

Мы чувствуем себя в большей безопасности таким гибридным способом. Нам не хватало автоматизации и обнаружения изменений схемы в Entity Framework Migrations так же, как нам не хватало управления строками версий в Dacpacs.

person Gustavo    schedule 27.04.2012
comment
Пользуясь FluentMigrator в прошлом, я не понимаю, почему вы просто не используете его. Это открытый исходный код, поэтому, если вам не нравится, как что-то работает, вы можете это изменить. Кажется, он сделает все, что вам нужно. - person jcollum; 17.05.2012