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

Question

У нас есть "основная структура базы данных", и нам нужна процедура для поддержания структуры базы данных на клиентских сайтах в актуальном состоянии.

Был выдвинут ряд предложений по смежному вопросу , но я ищу более конкретное решение по этим направлениям:

1. Я хотел бы создать текстовый файл (XML или другой читаемый формат), который описывает всю структуру базы данных (это может войти в контроль версий). Эта процедура будет выполняться собственными силами, чтобы предоставить файл схемы базы данных для распространения со следующей версией нашего продукта.
2. Тогда мне нужен способ обновить структуру базы данных на клиентском сайте, чтобы она соответствовала основной структуре базы данных. (Другими словами, я не хочу отслеживать многочисленные сценарии изменений для разных версий структуры базы данных, но более общую процедуру, которая может обновить структуру базы данных клиента до текущей основной структуры базы данных.)

Таким образом, основная функция, которую я ищу, может быть описана как «структура базы данных в текст» и «структура текста в базу данных».

Answer 1

Несколько популярных стратегий - варианты этого:

• Добавить таблицу в базу данных:
  CREATE TABLE Release
  (номер_публикации int не ноль,
  дата и время применения не равны
  )
• Каждый выпуск в рамках своего сценария выпуска вставляет строку в эту таблицу.
• Теперь вы можете с помощью одного запроса выяснить, какая версия работает на каждом клиенте, и запустить все версии между этой и той версией, которую они хотят запустить.
• Кроме того, вы можете проверить правильность их схемы для каждой версии (правильные имена таблиц, столбцы и т. Д.), Выполнив что-то вроде этого:
  ВЫБЕРИТЕ so.name,
  sc.name
  ОТ sysobjects так,
  системные столбцы sc
  ГДЕ тип = 'U'
  ЗАКАЗАТЬ НА 1, 2
• Затем вычислите хэш результата и сравните его с предварительно вычисленным хешем (сгенерированным путем выполнения запроса в вашей эталонной установке), чтобы убедиться, что установка сейчас правильная.

Answer 2

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

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

Если вы этого не сделаете, единственный другой здравомыслящий вариант, о котором я могу подумать, - это использовать идею миграции, сохранить список сценариев SQL + пары версий, а также текущую версию в каждой базе данных. Это может быть объединено с помощью другого инструмента, который может сгенерировать один скрипт из номера версии базы данных клиента и списка изменений. А если у вас нет списка изменений, вы можете начать с запуска инструмента diff и отслеживать их оттуда.

Сравнение текстового маршрута (сравнение текстовых дампов SQL обеих схем), который вы, похоже, предпочитаете, выглядит очень сложно, чтобы сделать это правильно и автоматически, не похоже на правильный путь.