Как да генерирам SQL скрипт за миграция от стара база данни към нова база данни?

Ние разработваме уеб базирано решение за клиент, използващ java и oracle 11g. Проектът е инсталиран за клиента, но повечето от неговите функции са в процес на разработка. Всеки месец пускаме нова версия, която трябва да бъде инсталирана на сайта на клиента. Проблемът е, че във всяко издание има много промени в DB (таблици, изгледи, SP, тригери и т.н.). Не мога да получа дъмпа от линията за разработка и да го пренеса на сайта на клиента.

Въпросът е как мога да генерирам SQL скрипт, който може да мигрира схемата на базата данни на клиента към нейната нова версия (версия за разработка)? Има ли някакъв автоматизиран инструмент за генериране на тези скриптове? Има ли код с отворен код в java, който може да направи това? Някакви най-добри практики за този проблем?

Редактиране

Според отговорите изглежда, че най-добрата практика е да се забрани на разработчиците директна промяна на DB Scheme и те трябва да напишат и ангажират скрипт за промяна за всяка актуализация на DB. Но използвайки този метод, след известно време ще има много скриптове за промяна, като всеки от тях съдържа специфична актуализация в DB. Как тогава мога да управлявам тези множество скриптове?


java sql oracle oracle11g
person Gupta    schedule 23.08.2012    source източник
comment
Мисля, че инструментите съществуват, но не знам име. Но начинът да управлявате това обикновено е да използвате VCS, който пази историята на вашите SQL скриптове, което ще управлява лесно модификацията между 2 дадени версии на софтуера. Например един скрипт creation.sql, който изгражда базата данни от нулата. друг, който се занимава с модификация. По този начин, когато доставите проекта за първи път, клиентът ще използва файла creation.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

TL; DR: Инструмент за разлика не може да определи контекста на конкретна промяна. Например, ако по време на вашата разработка сте коригирали правописна грешка в име на колона, бихте искали да използвате команда RENAME COLUMN в съществуваща база данни, за да запазите всички данни, които таблицата вече съдържа. Инструментът за разлики в база данни може да види само стара колона, която не съществува в новата схема, и по същия начин нова колона, която не съществува в старата схема. Така че инструментът ще премахне старата колона и ще добави новата, но в резултат на това всички данни, първоначално в тази колона, вече са изчезнали.

Бих препоръчал проактивно проследяване на промените в базата данни, като най-добра практика. По-новите уеб рамки като Django и Ruby on Rails поддържат проследяване на миграцията извън кутията, но решения с отворен код като Liquibase (тази връзка по-горе) съществуват и за света на Java. Ние използваме Liquibase в настоящата ми компания и постигнахме голям успех в минимизирането на тези разходи за миграция досега. Направихме превключването, след като преминахме през точно такава миграция, с която се сблъсквате сега.

Късмет!

person Peter Bratton    schedule 23.08.2012

arrow_upward
2
arrow_downward

Промените в базата данни трябва да се правят само чрез скриптове, които поставяте в контрола на източника. Ако направите това, тогава няма да имате много проблеми да знаете какво да преместите в Qa и след това в prod. Освен това скриптът е тестван за разлика от създаването на скрипт в края и стартирането му за първи път на prod. Освен това, ако някои промени са за различен проект, те няма да бъдат случайно пуснати в прод, когато не са готови, защото ще бъдат в различен клон на контрола на източника. SQL кодът е код, той трябва да се третира точно като всеки друг код по отношение на контрола на източника.

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