Миграция базы данных: управлять сценарием сборки или автоматически при запуске приложения? - PullRequest
Новая
       22

Миграция базы данных: управлять сценарием сборки или автоматически при запуске приложения?

3 голосов
/ 15 апреля 2009

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

Кажется, есть два пути:

  1. Используйте скрипт миграции, который может либо запускаться вручную из команды линия или как часть автоматического процесс развертывания / сборки
  2. Запустите миграцию, когда приложение запускается (я использую ASP.NET, так что это можно сделать достаточно легко без вызывая длительный запрос пользователя)

Есть ли у кого-нибудь какие-либо предложения / идеи / опыт использования этих подходов? Любые другие предложения?

Я понимаю, почему # 1 может быть более привлекательным - он дает мне полный контроль над обновлением БД. Тем не менее, мне очень нравится # 2, поскольку он позволяет быстро выполнять итерации между развертываниями и сокращает ручной процесс. № 2 также может быть использован на моей машине для разработки, чтобы позволить еще более быстрые итерации. Хм, начинаю думать, что иметь и то, и другое было бы хорошо ...

Ответы [ 4 ]

2 голосов
/ 15 апреля 2009

У нас есть система продаж с клиентом ~ 100, и мы обновляем базу данных при запуске приложения (правда, это настольное приложение.) Мне нравится этот подход, он безопасен и повторяется, если у нас есть неопределенная начальная точка (клиент база данных новая или только обновленная до версии xyz?).

Но на стороне сервера я предпочитаю ваш вариант № 1: мы создаем файл запроса SQL на нашей виртуальной машине (на основе копии исходной базы данных) и запускаем этот запрос на реальном сервере.

Так ИМХО:

  • Отключенные клиенты: запуск, итерационные сценарии
  • Сервер: запрос, созданный на виртуальной машине на основе фактической и реальной базы данных

Так что я тоже заинтересован в этой проблеме и нахожу некоторые (половину) фреймворки как RikMigrations . После некоторого поиска в Google есть хорошая стартовая площадка для создания версий / миграции баз данных: .NET Database Migration Tool Roundup . Не обязательно документация, но блоги команды могут быть интересными.

1 голос
/ 15 апреля 2009

Мне больше нравится вариант № 1, так как он кажется гораздо более гибким. Вместо того, чтобы фактически выполнять миграцию при каждом запуске приложения, я думаю, что я бы проверил, что схема базы данных (номер версии?) Соответствует коду, и если нет, выдаст предупреждение или ошибку о несоответствующей схеме базы данных.

0 голосов
/ 19 апреля 2009

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

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

0 голосов
/ 19 апреля 2009

Я бы предпочел вариант № 1 по ряду причин. Во-первых, интеграционные тесты обычно требуют, чтобы ваша схема БД была обновленной, и запуск веб-сайта для обновления схемы потребует огромных затрат времени. Во-вторых, вы не можете изменить схему базы данных, пока ваш сайт работает (скажем, добавить пару индексов, чтобы ускорить процесс).

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

И если вы ищете среду миграции, взгляните на Wizardby .

...