Какими способами можно связать базу Oracle (пакеты, триггеры, индексы, структура таблиц и т.д.) с системой контроля версий (GIT, SVN)?

Question

[DigitalGod]

Всем доброго времени суток.
Давно назревал вопрос и вот пришло время:
Какими способами можно связать базу Oracle (пакеты, триггеры, индексы, структура таблиц и т.д.) с системой контроля версий (GIT, SVN)?

Знаю есть несколько программных решений (RedGate и Liquibase). Так же приходит решение в лоб - все объекты прописать в sql файлах и уже их заносить в контроль версий.

Хотелось бы узнать как у Вас происходит работа с базой данных в команде? Как контролируется что и кто изменил.

Основная проблема - выяснить кто поменял конкретный объект базы (были печальные прецеденты). В довесок конечно же перенос данных с develop на production.

Answer 1

[mrstrictly]

Если речь идет о production-БД, то самый надежный и проверенный временем алгоритм, пожалуй -- следующий:
1. Изменения в БД оформляются в виде т.н. миграций. Движков для реализации SQL миграций -- полно. В простейшем случае, миграция -- это просто набор DDL/DML оформленных в виде, например, SQL-скрипта.
2. Миграции хранятся в VCS. Видно кто какие изменения в них вносил.
3. В продакшне миграции применяются автоматически под контролем DBA, либо руками самого DBA. Роль DBA может выполнять любое ответственное лицо, если у вас в штате не выделено отдельного человека.
4. (бонус) Схема БД в продакшне после каждого применения миграции выгружается в тот же VCS в виде отдельного скрипта и содержит только DDL и справочные данные (пример: данные для наполнения таблицы марок автомобилей, данные для наполнения таблицы стран и т.п.). Это удобно для быстрого развертывания разработческих окружений синхронных с текущей продакшн-схемой БД.
Как-то так.

Answer 2

[Алексей Киселев]

К сказанному @mrstrictly хочу добавить:

Обладать правами на изменение структуру БД на production должен очень ограниченный круг работников (или вообще один). У них должен быть очень простой алгоритм работы: взять последнюю версию скрипта миграции из ветки "xxx" и выполнить его после того как была отмашка от руководителя проекта.
Разработчики переносят изменения в ветку "xxx" из ветоки в которой ведется активная разработка после проверки на development БД. То есть они как бы делают релиз скрипта миграции.

Таким образом, если единственным источником DDL будет система контроля версий, это будет подталкивать разработчиков к внесению изменений в структуру БД через нее. И вы сможете отследить кто, что и когда менял.

Мне видится, в этой проблеме больше организационной работы.

Answer 3

[Geny]

Если "Основная проблема - выяснить кто поменял конкретный объект базы (были печальные прецеденты). ", то можно повесить триггер на схему и логировать изменения DDL

CREATE OR REPLACE TRIGGER ddl_log_and_lock_trigger
AFTER
CREATE OR ALTER OR DROP
ON SCHEMA
BEGIN
.....
END;