Создание сценариев обновления SQL для клиента

Question

Каков наилучший способ поддержки сценариев обновления между версиями продукта? Если клиент начинает с версии 3 вашего продукта и переходит к версии 5, каков наилучший способ создания сценария обновления для клиента, чтобы устранить любые различия в схеме базы данных между версиями 3 и 5?

Answer 1

1) Используйте такой инструмент, как Сравнение схемы и данных RedGate

2) Использование GDR-проекта Visual Studio 2008

3) Напишите свой собственный!

Answer 2

Это уже много раз обсуждалось:

Как автоматически обновить развернутую базу данных для конечных пользователей

Стратегии развертывания базы данных (SQL Server)

Доступны ли какие-либо инструменты управления изменениями баз данных SQL Server 2008?

Migrator.net представляется предпочтительным подходом в этих вопросах. Мне нравится такой подход, но если ваш случай прост, вы можете предпочесть сохранить SQL для выполнения изменений в таблице с номером версии, например:

create table upgradetable (major int, minor int, revision int, change text)

и тогда вы можете получить скрипт для выполнения обновления с помощью простого:

 select change from upgradetable where major > (select major from versiontable)

(конечно, по вкусу).

Это не будет работать, если вы не можете выполнить все обновления через SQL, и в этом случае я рекомендую migrator.net

Answer 3

Попробуйте Wizardby , чтобы увидеть, подходит ли он. Он имеет специальный DSL для написания миграций, он может автоматически генерировать сценарии понижения и отслеживает версии, поэтому вам не нужно писать какой-либо код для этого.

Если вы хотите выполнить обновления программно, см. this .

Answer 4

На самом деле, это довольно просто.
Подобно ветвлению в стандартных репозиториях кода, вам нужна стратегия управления исходным кодом, которая позволяет вам выполнять следующие действия:
а. Создайте ветку вашей базы данных в определенной точке. (v3 / v4).
б. Используйте эту ветку, чтобы восстановить базу данных до определенной версии. (т.е. v3 или v4).
с. Создайте набор сценариев исправлений для перехода с версии v3 на версию v4 или версию v3 на версию v5.
д. Протестируйте эти патчи перед отправкой вашему клиенту.

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

Посмотрите на DBSourceTools (http://dbsourcetools.codeplex.com), и, в частности, стратегию исправления.
Этот инструмент позволит вам создать базу данных в определенной точке и создать именованную версию (v1).
Затем создайте цель развертывания и увеличьте указанную версию до версии v2.
Наконец, добавьте сценарии исправлений в каталог исправлений для любых изменений схемы или данных.

Это дает вам повторяющийся процесс тестирования всех исправлений, которые будут применяться от v1 до v2.
DBSourceTools также имеет функции, помогающие вам создавать эти сценарии, то есть инструменты сравнения схем или данных сценариев.

Как только вы закончите, просто отправьте все файлы из каталога исправлений своему клиенту.

Веселитесь.

Answer 5

Управление версиями можно выполнить, следуя подходу, аналогичному тому, который используется для миграции dbdeploy или ruby ​​rake Вы последовательно нумеруете каждый скрипт обновления и имеете в базе данных таблицу, в которой хранятся все номера скриптов, которые уже были реализованы.

Средство обновления просто применяет сценарии с номерами выше, чем те, которые уже реализованы в базе данных.

Подробнее здесь .

Answer 6

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