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

Question

У меня есть рабочий процесс управления изменениями базы данных.Он основан на SQL-скриптах (таким образом, это не решение, основанное на управляемом коде).

Базовая настройка выглядит следующим образом:

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

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

Мой вопрос в том, полезно ли при такого рода настройке также поддерживать это:

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

Под "этим" я подразумеваю каталог сценариев (разделенных типом объекта), который представляет сценарии создания для раскручивания текущий / последняя версия версия базы данных.

По какой-то причине мне действительно нравится эта идея, но я не могу конкретно обосновать ее необходимость.Я что-то упускаю?

Преимущества были бы следующими:

• Для разработчиков и системы управления версиями у нас была бы та же настройка объекта для каждого файла, к которой мы привыкли
• Для развертывания мы можем развернуть новый экземпляр базы данных до последней версии либо путем запуска Initial + Migrate, либо путем запуска сценариев из текущего/
• Для разработчиков нам не нужен запущенный экземпляр DB для выполнения разработки.Мы можем выполнить "автономную" разработку в текущей папке /.

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

Мартин,

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

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

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