Синхронизация развивающейся схемы БД и сценариев аварийного восстановления - PullRequest
1 голос
/ 17 февраля 2010

У нас довольно большая схема БД, которая постоянно меняется - каждый выпуск приложения включает в себя само приложение, а также сценарий миграции, который при необходимости применяется к действующей БД.

Nopw, параллельно мы поддерживаем скрипт создания схемы, который мы можем использовать в любой момент для создания БД с нуля (для целей тестирования).

Меня немного огорчает то, что это кажется нарушением DRY - если я добавляю столбец в таблицу, мне нужно создать сценарий для этого и внести аналогичные скрипт построения схемы.

Есть ли стратегия, чтобы избежать этого? Я подумал о том, чтобы иметь «справочную БД» без динамических данных, которую мы могли бы просто экспортировать после каждой сборки. Итак, мы создаем сценарий миграции, а затем, когда сборка активна, экспортируем схему обратно в сценарий «create».

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

1 Ответ

0 голосов
/ 17 февраля 2010

У меня та же проблема / беспокойство / досада. Лучший способ найти единственный способ следовать DRY - использовать инструмент моделирования базы данных (например, CA Erwin, Sybase PowerDesigner), где вся работа по моделированию выполняется для построения / поддержки эталонной схемы. Затем вы можете использовать возможности инструмента для управления изменениями, чтобы сгенерировать как скрипт diff, который выполняется, чтобы перейти от выпуска A к выпуску B, так и самостоятельно сгенерировать эталонную реализацию.

Вы, конечно, можете обнаружить, что есть места, где вы не повторяли себя, но инструменты сравнения покажут все различия, так что вы можете сосать "О, я должен был изменить это на лету", и обратно эталонная реализация.

Очевидно, что все это - скрипт diff, эталонная реализация и сама модель - затем защищаются с помощью управления исходным кодом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...