Управление изменениями базы данных - устанавливает для начальной буквы, создают сценарии, последующие сценарии миграции
У меня есть рабочий процесс управления изменениями базы данных на месте. Это основано на сценариях SQL (так, это не основанное на управляемом коде решение).
Основная установка похожа на это:
Initial/
Generate Initial Schema.sql
Generate Initial Required Data.sql
Generate Initial Test Data.sql
Migration
0001_MigrationScriptForChangeOne.sql
0002_MigrationScriptForChangeTwo.sql
...
Процесс для вращения базы данных должен затем запустить все скрипты Initlal и затем запустить последовательные скрипты Миграции. Инструмент берет случай требований управления версиями и т.д.
Мой вопрос в этом виде установки, это полезный, чтобы также поддержать это:
Current/
Stored Procedures/
dbo.MyStoredProcedureCreateScript.sql
...
Tables/
dbo.MyTableCreateScript.sql
...
...
"Этим" я имею в виду каталог сценариев (разделенный типом объекта), который представляет создать сценарии для вращения текущей / последней версии базы данных.
По некоторым причинам мне действительно нравится идея, но я не могу конкретно выровнять по ширине, это - потребность. Я пропускаю что-то?
Преимущества были бы:
- Для dev и управления исходным кодом, у нас была бы та же установка объекта на файл, к которой мы привыкли
- Для развертывания мы можем вращать новый экземпляр DB к последней версии или путем выполнения Initial+Migrate, или путем запущения скриптов от Текущего /
- Для dev нам не нужно выполнение экземпляра DB, чтобы сделать разработку. Мы можем сделать "офлайновую" разработку на Текущей папке/.
Недостатки были бы:
- Для каждого изменения мы должны обновить сценарии в Текущей папке/, а также создать сценарий Миграции (в Миграции / папка)
Заранее спасибо за любой вход!
3 ответа
На самом деле, это лучший способ. Как бы громоздко это ни звучало, это лучше, чем альтернативы использованию инструментов сравнения SQL или развертыванию файла VSDB .schema. Я уже некоторое время отстаиваю именно подход smae: Контроль версий и ваша база данных . Мои приложения развертывают схему v1 из исходного сценария, а затем запускают сценарий обновления для каждой версии. Каждый скрипт умеет обновляться с версии N-1 до N, и только. Конечный результат - текущая версия.
Самым большим недостатком является отсутствие авторитетного файла .sql, чтобы найти текущую версию любого объекта (процедуры, таблицы, представления и т. Д.). Но преимущества возможности развертывания приложения по сравнению с любой предыдущей версией, а также преимущество развертывания с помощью хорошо контролируемых и протестированных сценариев намного перевешивают этот недостаток.
Если вам не нравится использовать этот процесс развертывания (сценарий для развертывания v1. Затем примените v1.1, затем v1.2 ... пока, наконец, вы не примените v4.5, current), имейте это в виду: точно так же Процесс используется SQL Server внутри для обновления базы данных между выпусками. Когда вы присоединяете старую базу данных, вы видите знаменитую «база данных выполняет обновление с версии 611 до 612», и вы видите, что обновление идет шаг за шагом , а не сразу до текущей версии 651 (или все, что актуально в вашем случае). Также при обновлении не запускается инструмент diff для развертывания версии 651 по сравнению с версией 611.Это потому, что лучший подход - это тот, который вы просто используете, обновляя шаг за шагом.
И чтобы добавить реальный ответ на ваш вопрос, после публикации довольно уклончивой тирады (Вы можете сказать, по этой теме у меня есть твердое мнение?): Я считаю, что иметь скриптовую версию текущей версии полезно, но Я думаю, что это должен быть результат процесса непрерывной интеграции. Другими словами, ваш сервер сборки должен построить текущую базу данных (используя сценарии обновления), а затем, в качестве шага сборки, создать сценарий базы данных и произвести отбрасывание сборки с помощью сценария схемы текущей версии. Но их следует использовать только как справочник для поиска и проверки кода, а не как результат развертывания, как мой 2C.
Я думаю, что в конечном итоге это только усложнит ситуацию. Целые версии должны находиться в одном скрипте, чтобы вы могли протестировать этот скрипт в одном контексте и знать, что он будет правильно работать в другом контексте, например в производстве.
Мартин,
Если вы находитесь в реальном мире, ваша производственная база данных принимает только обновления - вы никогда не «создаете» ее с нуля. Итак, самое важное, что вы должны хранить, смотреть, просматривать и т. Д., - это набор скриптов обновления. Это сценарии, которые будут запущены в производство, так что это единственные действительно важные сценарии.
Вы поступаете правильно, делая их главными. Но разработчики должны иметь возможность получить «текущую картину» того, как выглядит схема. Администраторы баз данных тоже любят это делать, хотя (слишком) часто они делают это, войдя в систему на производственных серверах и запустив какой-нибудь инструмент с графическим интерфейсом. (yikes!)
Единственное, что у меня есть относительно вашего подхода, - это текущая / предыдущая схема по типу объекта . Эти сценарии должны создаваться автоматически из дампа самой базы данных. Если вы можете автоматически классифицировать их по типу, тогда отлично! Если нет, сделайте все возможное, чтобы упростить навигацию по ним, но руководящее правило всегда должно «генерироваться автоматически из действующей базы данных».