Миграции базы данных SQL Server JDBC

Question

Я работаю над веб-приложением Java (интерфейсом Adobe Flex, интерфейсом JPA/Hibernate/BlazeDS/Spring MVC) и скоро достигнет точки, когда я больше не могу стереть базу данных и регенерировать Это.

Каков наилучший подход для обработки изменений в схеме БД? Базы данных производства и тестирования - это SQL Server 2005, dev - использование MySQL, а модульные тесты - против базы данных в базе данных HSQLDB. Я в порядке, когда dev-машины продолжают стирать и перезагружать БД из выборочных данных с помощью Hibernate для регенерации таблиц. Однако для развертывания производства администратор базы данных хотел бы иметь сценарий DDL, который он может выполнить вручную.

Итак, мое идеальное решение было бы тем, где я мог бы писать миграции в стиле Rails, выполнять их на тестовых серверах и после проверки того, что они работают, смогут записывать DDL SQL Server, который может выполнять администратор базы данных на производстве серверов (и которые уже были проверены для повторного запуска тестовых серверов).

Что это отличный инструмент для этого? Должен ли я писать DDL вручную (и просто позволить dev-машинам использовать Hibernate для регенерации БД)? Могу ли я использовать такой инструмент, как migrate4j (который, кажется, имеет ограниченную поддержку SQL Server, если вообще)?

Я также хочу интегрировать сценарии манипуляции DB в этот процесс (например, преобразование поля «Имя» в поле «Имя», «Фамилия» через сценарий JDBC, который разбивает все существующие строки) ,

Любые предложения были бы высоко оценены!

Answer 1

Каков наилучший подход для обработки изменений схемы БД?

Идемпотентного change scripts с версией таблицей (и инструментом для применения всех сценариев изменения с номером, большим, чем версия в настоящее время хранится в таблице версии). Также проверьте упомянутый пост Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views.

Для реализации этого, вы можете раскатать свои собственные решения или использовать существующие инструменты, такие как DbUpdater (упоминается в комментариях change scripts) LiquiBase или dbdeploy. Позже мое предпочтение.

Answer 2

Я полагаюсь на спящий режим, чтобы создать все, что ему нужно на производственном сервере. Нет никакого риска потерять данные, потому что он никогда ничего не удаляет: он добавляет только то, чего не хватает.

В текущем проекте мы установили соглашение, согласно которому любая функция, требующая изменения в базе данных (схема или данные), требуется для предоставления ее собственных фрагментов DDL/DML, что означает, что все, что нам нужно сделать, это объединить фрагменты в один скрипт и выполнить его, чтобы обновить производство. Ничто из этого не работает в очень больших масштабах (порядок фрагментов становится критическим, не каждый следует за конвенцией и т. Д.), Но в небольшой команде и итеративном процессе это работает отлично.