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

Question

У меня есть рабочий процесс управления изменениями базы данных. Он основан на сценариях 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 и source control у нас будет такая же настройка объекта на файл, которую мы использовали для
• Для развертывания мы можем ускорить новый экземпляр БД до последней версии, запустив Initial + Migrate или запустив сценарии из Current /
• Для dev нам не нужен экземпляр БД, запущенный для разработки. Мы можем выполнять «автономную» разработку в папке Current /.

Недостатками будут:

• Для каждого изменения нам нужно обновить скрипты в папке Current /, а также создать скрипт миграции (в папке Migration /)

Заранее спасибо за любой вклад!

Answer 1

На самом деле, это лучший способ. Как бы громоздко это ни звучало, это лучше, чем альтернативы использования SQL Compare-подобных инструментов или развертывания файла VSDB .schema. Я уже некоторое время отстаиваю именно такой подход к smae: Контроль версий и ваша База данных . Мои приложения развертывают схему v1 из исходного сценария, затем запускают сценарий обновления для каждой версии. Каждый скрипт знает, как перейти с версии N-1 на N, и только это. Окончательный результат - текущая версия.

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

Если вам не нравится этот процесс развертывания (сценарий для развертывания v1. Затем примените v1.1, затем v1.2 ... пока, наконец, не примените v4.5, текущий), имейте это в виду: точно так же Процесс используется SQL Server для обновления базы данных между выпусками. Когда вы присоединяете более старую базу данных, вы видите, что известная «база данных выполняет обновление с версии 611 до 612», и вы видите, что обновление идет шаг за шагом , не обновляется прямо до текущей версии 651 (или что бы ни было актуально в вашем случае). При обновлении также не запускается инструмент diff для развертывания v 651 по сравнению с v. 611. Это связано с тем, что подход best - это тот, который вы только что использовали, обновляйте один шаг за раз.

И чтобы добавить реальный ответ на ваш вопрос, после публикации довольно косой темы (у вас есть твердое мнение о теме, можете ли вы сказать?): Я думаю, что полезно иметь текущую версию со скриптом, но Я думаю, что это должен быть непрерывный процесс сборки интеграции. Другими словами, ваш сервер сборки должен построить текущую базу данных (используя сценарии обновления), а затем, в качестве шага сборки, создать сценарий для базы данных и произвести сброс сборки с помощью сценария схемы текущей версии. Но они должны использоваться только как справочник для поиска и проверки кода, а не как результат развертывания, мой 2C.

Answer 2

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

Answer 3

Martin

Если вы находитесь в реальном мире, то ваша производственная база данных принимает только обновления - вы никогда не «создаете» ее с нуля. Поэтому наиболее важным для вас является сохранение, просмотр, просмотр и т. Д. Набор сценариев обновления. Это те сценарии, которые дойдут до производства, так что это единственные, которые действительно важны.

Вы делаете правильные вещи, делая их первичными. Но разработчики должны иметь возможность получить «текущую картину» того, как выглядит схема. Администраторы баз данных тоже любят это делать, хотя (слишком) часто они делают это, выполняя вход на рабочие серверы и запуская некоторый графический инструмент. (Yikes!)

Единственная оговорка, касающаяся вашего подхода, - это текущая / предыдущая схема по типу объекта . Эти сценарии должны генерироваться автоматически из дампа самой базы данных. Если вы можете автоматически классифицировать их по типу, то отлично! Если нет, сделайте все возможное, чтобы облегчить их навигацию, но руководящее правило всегда должно «генерироваться автоматически из действующей базы данных».