Oracle DDL / DML-скрипт, PL / SQL в Source Control

Question

Я ищу рекомендации / рекомендации о том, как лучше хранить сценарии DDL / DML и PL / SQL в Source Control (мы используем Microsoft Visual Studio TFS) для собственного SaaS-приложения.

У нас есть команда из 7 разработчиков, работающих над проектом, основанным на довольно простой модели ветки Dev / Main. Между сценариями существуют зависимости (прежде всего порядок выполнения).

Что сработало для вас в подобных обстоятельствах?

Answer 1

Мы создали инструмент, который может управлять кодом PL / SQL (или любым другим объектом, который может быть создан с помощью команды CREATE OR REPLACE) в базе данных Oracle. Он подключает Git к базе данных Oracle.

Вы можете выполнять основные задачи Git, такие как фиксация, сброс, ветвление, клонирование, объединение, извлечение и т. Д., И Gitora автоматически обновляет код PL / SQL в базе данных.

Он не обрабатывает таблицы, так что это все еще ручная задача.

Мы решили сделать Gitora доступной для всех бесплатно. Выходит в декабре 14 года. Вы можете зарегистрироваться, чтобы получать уведомления на www.gitora.com

Answer 2

Почему вы хотите сохранить сценарии DDL? Вы никогда не сможете использовать их снова. Вы не можете доверять им, не сравнивая их с производством. Единственная причина, по которой я бы сохранил DDL (кроме того, что это звучит как хорошая идея), - это возможность сравнивать полные базовые строки, помещая каждую схему в один файл. Это позволит вам выполнить различие перед развертыванием, чтобы увидеть изменения.

Я проверил в DDL на многих проектах и ​​обнаружил, что путем создания изменений в верхней части проверки исходного кода вместо того, что в Prod. мы потеряли изменения.

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

На мой взгляд, это звучит хорошо, но на практике не работает.

Answer 3

Вы можете прослушивать через LiquiBase (http://en.wikipedia.org/wiki/LiquiBase) LiquiBase - это независимая от базы данных библиотека с открытым исходным кодом для отслеживания, управления и применения изменений в базе данных. (XML основе)

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

Я собираюсь использовать этот инструмент для отслеживания изменений в базе данных DML, PLSQL с контролем версий GIT.

Answer 4

Упрощенный взгляд на ногу в нашем контроле исходного кода будет:

\DatabasePatches
  \Core
  \Data
\DatabaseSource
  \Core
    \SchemaA
    \SchemaB
    \SchemaC

DDL для определенной части работы написан и проверен под основными исправлениями с DML / миграцией, зарегистрированной под исправлениями данных. Часть метки патча представляет собой порядковый номер (вручную добавляйте 10 каждый раз, чтобы разрешить будущую вставку патчей между ними), поэтому патч может называться «DATAPATCH01530 - migrate of xyz.sql».

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

Как только патч был запущен в новом месте, файл помечается как ФИНАЛЬНЫЙ в исходном контроле (мы используем PVCS и блокируем файл с именем пользователя ФИНАЛ), чтобы убедиться, что он не может быть изменен и вызвать несогласованность. Любые дополнительные изменения должны быть включены в отдельный патч.

Хранимые процедуры, функции, пакеты и т. Д. Сохраняются и регистрируются в разделе DatabaseSource. Вы не можете гарантировать, что эти объекты будут продвинуты до запуска сценариев, поэтому мы учитываем это, создавая заглушки в наших сценариях (например, представления будут создаваться как SELECT '1' FROM dual, пакеты будут содержать фиктивную процедуру), которые гарантируют объект существует и позволяет вам предоставлять привилегии и т. д. Когда фактический объект продвигается, он заменяет заглушку и сохраняет привилегии.

Answer 5

Мы держали сценарии DDL под контролем исходного кода, а для DML мы использовали нечто похожее с этим: http://dbdeploy.com/,, но наши были написаны на Perl, так что это было немного неловко

Answer 6

См. мой ответ до Как вы должны построить свою базу данных из системы контроля версий? . Он в основном основан на превосходном K. Скотт Аллен серия на эту тему.