Схема управления версиями Oracle DB

Question

Просто интересно, кто-нибудь когда-нибудь задумывался / реализовывал что-то подобное.

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

Это имеет смысл? Кто-нибудь видит какие-то огромные дыры в этом, кроме того факта, что это будет происходить раз в день?

Кто-нибудь делал что-то подобное?

Answer 1

Вот сообщение в блоге какого-то случайного парня на эту тему. Он ссылается на несколько хороших статей, чтобы дать идеи.

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

Answer 2

Не уверен, что вы видите, как использовать для этого. Я бы склонялся к триггерам AUDIT и / или DDL, чтобы фиксировать изменения кода в базе данных.

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

Одна мысль состоит в том, что иногда справочные данные так же важны, как и код.

Answer 3

Что-то вроде Workspace Manager, хотя и для контроля версий данных:

http://www.oracle.com/technology/products/database/workspace_manager/index.html

Answer 4

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

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