Как сгенерировать SQL-скрипт для миграции со старой БД на новую?

Мы разрабатываем веб-решение для клиента, использующего Java и Oracle 11g. Проект установлен у заказчика, но большая часть его возможностей находится в стадии разработки. Каждый месяц мы выпускаем новую версию, которую необходимо установить у клиента. Проблема в том, что в каждом релизе в БД много изменений (таблицы, представления, SP, триггеры и т.д.). Я не могу получить дамп с линии разработки и передать его заказчику.

Вопрос в том, как я могу создать сценарий SQL, который мог бы перенести схему клиентской БД в ее новую версию (версию для разработки)? Есть ли какой-нибудь автоматизированный инструмент для создания этих скриптов? Есть ли какой-нибудь открытый исходный код в java, который мог бы это сделать? Любые лучшие практики для этой проблемы?

Изменить

Согласно ответам, кажется, что лучше всего запретить разработчикам прямое изменение схемы БД, и они должны написать и зафиксировать сценарий изменения для каждого обновления БД. Но, используя этот метод, через некоторое время будет существовать множество сценариев изменений, каждый из которых содержит определенное обновление в БД. Как мне тогда управлять этой массой скриптов?


java sql oracle oracle11g
person Gupta    schedule 23.08.2012    source источник
comment
Я думаю, что инструменты существуют, но я не знаю ни одного названия. Но способ справиться с этим обычно заключается в использовании VCS, которая хранит историю ваших сценариев SQL, которые легко управляют модификацией между двумя заданными версиями программного обеспечения. Например, один скрипт create.sql, который создает базу данных с нуля. другой, который занимается модификацией. Таким образом, когда вы доставляете проект в первый раз, клиент будет использовать файл create.sql, в противном случае update-1.2.1.sql (например:) Надеюсь, это поможет в следующий раз. С Уважением.   -  person    schedule 23.08.2012

Ответы (2)


arrow_upward
5
arrow_downward

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

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

http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html

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

Я бы порекомендовал активно отслеживать изменения в базе данных по ходу работы. Более новые веб-фреймворки, такие как Django и Ruby on Rails, поддерживают отслеживание миграции «из коробки», но решения с открытым исходным кодом, такие как Liquibase (ссылка выше), существуют и для мира Java. Мы используем Liquibase в моей нынешней компании и до сих пор добились больших успехов в минимизации этих затрат на миграцию. Мы сделали переход после того, как проделали именно такую ​​миграцию, с которой вы сейчас сталкиваетесь.

Удачи!

person Peter Bratton    schedule 23.08.2012

arrow_upward
2
arrow_downward

Изменения в базу данных следует вносить только с помощью сценариев, которые вы помещаете в систему управления версиями. Если вы это сделаете, у вас не будет проблем с пониманием того, что нужно переместить в Qa, а затем прод. Кроме того, сценарий был протестирован, в отличие от создания сценария в конце и его первого запуска в рабочей среде. Кроме того, если некоторые изменения предназначены для другого проекта, они не будут случайно помещены в рабочую среду, когда они не готовы, потому что они будут находиться в другой ветке системы управления версиями. Код SQL — это код, с ним следует обращаться точно так же, как и с любым другим кодом с точки зрения системы управления версиями.

person HLGEM    schedule 23.08.2012
comment
Но, используя ваш метод, через некоторое время будет существовать множество сценариев изменений, каждый из которых содержит определенное обновление в моей БД. как мне тогда управлять этой массой скриптов? - person Gupta; 24.08.2012