Сценарии перемещения данных Visual Server Database Project выполняются в базах данных разных версий.

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

Недавно я прочитал два сообщения Barclay Hill.

Управление перемещением данных во время развертывания (часть 1)
Управление перемещением данных во время развертываний (часть 2)

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

Сценарий

Версия 1

Таблица1
СтолбецABC CHAR(1)

Версия 2

Таблица1
СтолбецXYZ INT

Перемещение данных из версии 1 в версию 2

Сценарий перед развертыванием проверяет версию базы данных и, если это версия 1, помещает данные из ColumnABC во временную таблицу.

Сценарий после развертывания проверяет, что мы сейчас находимся в версии 2, и проверяет существование временной таблицы, созданной в сценарии перед развертыванием, и помещает ее в новый столбец ColumnXYZ после преобразования char в int.

Версия 3

Table1
Column123 INT

Когда мы обновляем базу данных с версии 1 на версию 2, а затем на версию 3, все работает нормально. Однако, если у нас есть база данных версии 1 и мы хотим перейти к версии 3, сценарий после развертывания завершится ошибкой, потому что нет ColumnXYZ, поскольку теперь это Column123.

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


person Bronumski    schedule 25.11.2011    source источник


Ответы (2)


Извините, что вы не получили никакого ответа здесь. Удалось ли вам в итоге что-то придумать?

Я только начал исследовать «чувака с данными», и все эти движения данных определенно кажутся слоном в комнате.

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

(Пожалуйста, дайте мне знать. Я все еще пытаюсь решить, инвестировать ли в это или просто пойти по классическому пути DIY.)

person Benjol    schedule 09.08.2012

Как я вижу, у вас есть как минимум два варианта:

1) Требуется путь обновления 1->2->3.

2) Измените движение данных ColumnABC-ColumnXYZ на следующее:

  • Pre:
    • (if ColumnXYZ does not exist)
      • Add column ColumnXYZ (int)
      • Установите ColumnXYZ = [некоторое преобразование ColumnABC]
  • Install:
    • Adding ColumnXYZ is skipped because it is already there.
  • Post:
    • No action required
person S Koppenol    schedule 15.10.2013