Предложения по развертыванию / обновлению нескольких баз данных SQL Server 2005

Question

У нас есть продукт, который использует несколько баз данных SQL Server 2005 с триггерами. Мы ищем устойчивое решение для развертывания и обновления схем баз данных на клиентских серверах.

В настоящее время мы используем SQL Packager Red Gate, который, как представляется, не подходит для этой конкретной работы. Мало того, что SQL Packager, по-видимому, ориентирован на отдельные базы данных, но у конкретной (старой) версии, которой мы владеем, есть некоторые проблемы с SQL Server 2005. (Наша версия SQL Packager прекрасно работала с SQL Server 2000, хотя нам пришлось много обходных путей для обработки нескольких баз данных с помощью триггеров.)

Может ли кто-нибудь предложить продукт, который может создать проект EXE или .NET для следующих действий?

* Create a main database with some default data.
* Create an audit trail database. 
* Put triggers on the main database so audit data will automatically be inserted into the audit trail database.
* Create a secondary database that has nothing to do with the main database and audit trail database.

И затем, когда клиенту необходимо обновить схему базы данных, продукт может посмотреть на изменения между исходным набором баз данных и обновленным набором баз данных на нашем сервере. Затем продукт может создать проект EXE или .NET, который может на сервере клиента ...

* Temporarily drop triggers on the main database so alterations can be made.
* Alter database schemas, triggers, stored procedures, etc. on any of the original databases, while leaving the customer's data alone.
* Put the triggers back on the main database.

По сути, мы ищем продукт, похожий на SQL Packager, но который будет легко обрабатывать несколько баз данных. Если такого продукта не существует, нам придется сделать наш собственный.

Заранее спасибо за ваши предложения!

Answer 1

Я сам искал этот продукт, зная, что решение RedGate отлично работает для «одной» БД; к сожалению, мне не удалось найти такой инструмент: (

В конце концов, мне пришлось свернуть свое собственное решение, чтобы сделать что-то «похожее». Это была боль в ... , но это сработало.

Мой сценарий был намного проще, чем ваш, поскольку у нас не было триггеров и T-SQL.

Позже я решил пойти другим путем:

Каждое изменение БД имело СЦЕНАРИЙ. Номерные. 001_Create_Table_xXX.SQL, 002_AlterTable_whwhat.SQL и т. Д.

Независимо от того, насколько малы изменения, должен быть сценарий. Новая версия средства обновления делает это:

1. Делает BKP клиентаDB (на всякий случай)
2. Начинает выполнение скриптов в алфавитном порядке. (001, 002 ...)
3. Если скрипт завершается ошибкой, он отбрасывает BD. Регистрирует ошибку сценария, номер сценария и т. Д. И восстанавливает базу данных клиента.
4. Если он завершает работу, он создает еще одну резервную копию БД клиента (после «миграции») и обновляет таблицу, в которой мы храним версию БД; эта таблица проверяется приложением, чтобы убедиться, что база данных и приложение синхронизированы.
5. Показывает хороший успех MSG.

Это оказалось немного более "ручным", но оно действительно работало без особых усилий в течение трех лет. Секрет заключается в том, чтобы сохранить несколько тестируемых БД для проверки «обновления» перед развертыванием. Но кроме нескольких изолированных БД, где некоторые скрипты не работали из-за несогласованности данных, это работало нормально.

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

Answer 2

На момент написания этой статьи (июнь 2009 года) на рынке еще нет продукта, который бы делал все это для нескольких баз данных. Я работаю на Quest Software, создателя Change Director for SQL Server, еще одной системы автоматизации изменений баз данных. Наша не обрабатывает несколько баз данных, как вы, а я видел другие там. Без кубиков.

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