Как сказал ACP , функция Editions хорошо подойдет для этого, если у вас последняя и лучшая версия Oracle.
В любом случае другой связанный ответ показывает путь - сохранить все PL / SQL в управлении версиями и сохранить все изменения DDL в виде патчей, которые также вводятся в управление версиями.
Несколько практических вопросов, которые могут повлиять на ваше дело.
Если у вас относительно унифицированная структура базы данных и быстро меняющиеся пакеты PL / SQL, то вариант состоит в том, чтобы иметь одну схему, содержащую таблицы и основную ветвь пакетов PL / SQL, и дать каждому разработчику отдельную схему для своей ветви. PL / SQL пакеты. Все таблицы в основной схеме синонимичны каждой схеме разработчика.
Итак, у вас есть несколько версий PL / SQL, работающих с одним хранилищем данных. По мере того, как ветки разработчика собираются вместе, они проверяются в основной ветке и компилируются в основную схему приложения.
Мне проще иметь все пакеты pl / sql в каждой схеме разработки, а не только те, которые в данный момент находятся в разработке, но вы можете заставить его работать в любом случае.
Очевидно, что вам все еще нужны как минимум 2 базы данных, чтобы ваша производственная среда была защищена от всех этих махинаций.
Еще один вариант, если у вас это просто не работает, - предоставить каждому разработчику свою собственную базу данных, в которой можно повозиться. Вы сказали, что размер является здесь препятствующим фактором, но вы можете использовать функции Data Pump для ограничения количества строк, которые передаются из основной базы данных в каждую базу данных разработчика.
Например:
Чтобы экспортировать только 5% строк ...
$ expdp sample=5
Чтобы экспортировать только 5% определенной таблицы ...
$ expdp sample=mybigtable:5
Таким образом, каждый разработчик может работать с одной и той же структурой базы данных, но у вас нет одинаковых проблем с хранилищем.
Надеюсь, это поможет.