Максим Н http://www.dbmaestro.com/

+1 Рекомендую - очень достойный инструмент. Мы когда себе выбирали систему контроля версий для БД - он был у нас на первом месте. Не прижился по политическим причинам. Он умеет делать check-in/check-out объектов прямо в базе данных - т.е. работает для случая когда Вася с Петей не могут/не хотят договориться.

Разработчики достаточно хорошо понимают что такое версионная разработка - и достаточно отзывчивы.

[quot скв]кое-кто2 так никто не мешает договориться в качестве источника редактирования использовать файлы для хранимого plsql со всем функционалом системы контроля версий.

с PLSQL все понятно - там единица деплоймента - целый файл (самодостаточный)-
т.e.

CREATE OR REPLACE PROCEDURE ....
END;


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

ддляторА как dbmestro определяет, что ты решил править таблицу?
а структура таблицы заблокирована. чтобы изменить структуру таблицы тебе надо сделать ей check-out сначала.
ддляторВ случае с таблицами держится эталонный файл c ddl создания.
Система патчей - это уже скрипты с альтерами, которые сами по себе версионировать бессмысленно.
глобально есть два способа версионности базы данных
- держать DDL create table и вычислять разницу чтобы сгенерировать патч (как делает dbmaestro)
- держать под контролем именно все ALTER - как делают, например, Liquibase/dbup/roundhouse/... .

есть плюсы и минусы у каждого подхода.

ренамекое-кто2пропущено...

а структура таблицы заблокирована. чтобы изменить структуру таблицы тебе надо сделать ей check-out сначала.Заблокирована при правке через форму правки? Что делать с правками, недоступными через интерфейс или, если генерируемый формой код не устроил. Например, create or replace view грохает констрейнты и комменты на нее.

Заблокирована прямо в базе. Не имеет значения какой софт использовать чтобы сделать изменения в базе. Нужно только с помощью
dbMaestro сделать checkout объекта - иначе все alter table упадут с ошибкой что изменения невозможны. Если ты сказал в базе create or replace view - ты и убил констрейнты и комменты - это твое дело их воссоздать. А как только ты воссоздал, dbMaestro повторит это (с точностью до багов, если они есть в этом месте :) )

ренамекое-кто2глобально есть два способа версионности базы данных
- держать DDL create table и вычислять разницу чтобы сгенерировать патч (как делает dbmaestro)
- держать под контролем именно все ALTER - как делают, например, Liquibase/dbup/roundhouse/... .

есть плюсы и минусы у каждого подхода.Первый вариант применим только для крайне узкого круга правок структуры. Сохранить ддл в процессе разработки не составляет труда, в отличие от разгребания явных и неявных зависимостей результата сравнения объектов. ddl-diff пригоден только для контроля последствий.
1. CREATE TABLE ddl устаревает в момент первого исполнения. Чтобы изменить таблицу потом - он уже не поможет.
2.авторесть плюсы и минусы у каждого подхода
3. Как насчет того, чтобы выстроить последовательнось выполнения 17000 скриптов для патча? Чем это отличается от "разгребания явных и неявных зависимостей" но которые известны и правила не меняются?