Обновление базы данных SQL Server из сценариев SQL при установке

Question

Наш текущий сценарий выглядит так:

• у нас есть существующая база данных, которую необходимо обновлять для каждого нового выпуска, который мы устанавливаем
• мы должны сделать это из отдельных сценариев SQL (мы не можем использовать инструменты сравнения / сравнения БД)
• установка должна запускать сценарии SQL как можно более автоматически
• установка должна запускать только те сценарии SQL, которые не запускались до
• установка должна вывести отчет о том, какой скрипт выполнялся, а какой нет
• установка выполняется ИТ-персоналом заказчика, который не очень хорошо разбирается в SQL

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

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

Да, я знаю о SQLCMD - но это кажется "слишком базовым" - или нет?

Кто-нибудь там делает то же самое? Если так - как? Используете ли вы какой-либо инструмент, и если да, то какой?

Спасибо за любые идеи, предложения, мысли, указатели на инструменты или методы, которые вы используете!

Марк

Answer 1

У меня похожая ситуация. Мы поддерживаем сценарии объекта базы данных в управлении версиями. Для выпуска соответствующие версии помечены и извлечены из контроля версий. Пользовательский сценарий объединяет сценарии отдельных объектов в набор Create_DB, Ceate_DB_Tables, CreateDB Procs, ... На предыдущей работе я использовал созданные вручную пакетные файлы и OSQL для запуска сценариев создания / обновления базы данных.

В моей текущей позиции у нас есть InstallSheild, настроенный с помощью специального «Помощника установки», написанного на C ++, для вызова сценариев базы данных с использованием SqlCmd.

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

Звучит сложно, но работает довольно хорошо.

Answer 2

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

Внутренне он поддерживает таблицу SchemaInfo, которая отслеживает, какие миграции (версии) были применены к конкретному экземпляру базы данных, поэтому он может надежно запускать только требуемые.

Answer 3

У меня есть настройки, аналогичные этой, и это мое решение:

Иметь таблицу dbVersion, в которой хранится номер версии и отметка даты и времени. Имейте fodler, где сценарии сохранены с системой нумерации, например. х [000] Имейте приложение консоли / GUI, которое запускается как часть установки и сравнивает номер dbVersion с номерами файлов. Запускайте каждый новый файл по порядку в транзакции.

У нас это работает довольно долго.

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

Answer 4

Если вы сохраняете свои изменения в системе контроля версий (например, SVN), вы можете использовать пакетный файл с SQLCMD для развертывания только самых последних изменений из определенной ветви SVN.

Например,

rem  Code Changes
sqlcmd -U username -P password -S %1 -d DatabaseName    -i   "..\relativePath\dbo.ObjectName.sql"

Допустим, вы поддерживаете ветку SVN специально для развертывания. Вы передадите свой код в эту ветку, а затем выполните командный файл, который будет развертывать нужные объекты.

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