Инструменты для работы с хранимыми процедурами в Oracle, в команде?

В новый SQL Developer от Oracle встроен контроль версий.

Вот ссылка на товар.

http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html

http://www.oracle.com/technology/products/database/sql_developer/images/what_version.png http://www.oracle.com/technology/products/database/sql_developer/images/what_version.png

Относительно простым (хотя и немного старомодным) решением могло бы быть использование системы управления версиями в режиме «блокировки», а не в режиме «слияния» .... Subversion или CVS обычно используют режим «слияния» (хотя я считаю, что Subversion можно сделать "заблокировать" файлы?)

Системы контроля версий в "блокирующем" режиме, конечно, имеют свои недостатки ...

Единственный способ, который я могу придумать в Oracle, - это что-то из BEFORE CREATE TRIGGER, возможно, ссылка на таблицу для поиска, кто может запустить пакет. Хотя звучит немного противно?

Используя Oracle SQL Developer 1.5, вы можете легко создавать и управлять подключениями к CVS или Subversion. Чтобы создать соединение CVS (например), щелкните Управление версиями -> CVS -> Проверить модуль. Вы запустите мастер для создания соединения (хост, имя пользователя и т. д.), Затем вы сможете проверить свои процедуры / функции как в обычном режиме, так и в обычном режиме.

Интеграция с CVS также предусмотрена в Жаба.

Жаба также делает это, не требуя CVS / SVN.

Относитесь к PL / SQL как к обычному коду: храните его в файлах и управляйте этими файлами с помощью инструмента контроля версий и внутренних процедур.

Если у вас еще нет инструмента контроля версий, запишите свои требования и забрать один. Кажется, что многие люди используют Subversion, связанный с TortoiseSVN, в качестве клиента в Windows (я делаю).

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

В моем случае мне нравится использовать TortoiseSVN, как указано выше. И как обычно с этим инструментом:

• Я никогда не блокирую файлы. Это очень удобно для небольших команд и требует заблаговременного планирования для более крупных, что всегда хорошо, ИМХО.
• Я отправляю свои изменения вручную обратно на сервер, потому что ... Я не думаю, что есть другой способ с Subversion (плюс, внутренние процедуры запрещают фиксацию без сообщения, что тоже хорошо, ИМХО).

И что бы вы ни выбрали, я рекомендую прочитать этот пост (и связанные с ним) о управление версиями базы данных.

Вы также можете посмотреть Aqua Data Studio. Они также встроили в SVN и являются отличным редактором хранимых процедур.

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

В исходном сообщении запрашивалась возможность:

To automatically "lock" the current procedure you are working with, so nobody else in the team can make changes to it until you are finished.

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

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

Еще один прием, который я использовал в прошлом (в небольших командах), когда было невозможно позволить каждому разработчику иметь собственную копию данных из-за размера, заключался в том, чтобы иметь основную схему со всеми таблицами и кодом в ней, с общедоступными синонимами, указывающими на все это. Затем, если разработчик хочет работать с сохраненной процедурой, он просто создает ее в схеме его. Таким образом, разрешение имен Oracle сначала обнаруживает, что это одно, а не копия в главной схеме, что позволяет им тестировать свой код, не затрагивая никого другого. У этого есть свои недостатки, но это был очень специфический случай, когда мы могли с ними жить. Я бы НИКОГДА не стал внедрять что-то подобное в производство.

Что касается второго требования:

To automatically send the changes you make in the stored procedure, in an Oracle database, to a Subversion, CVS, ... repository

Я был бы удивлен, если бы нашел инструменты, достаточно умные для этого (возможно, возможность :). Ему нужно будет подключиться к вашей базе данных, запросить словарь данных (USER_SOURCE) и вытащить связанный текст. Сложная задача для систем управления версиями, где почти всегда используются файлы.

После неудачных поисков инструмента для управления версиями объектов Oracle мы создали следующее (не идеальное, но подходящее) решение:

1. Используя пакет dbms_metadata, мы создаем дамп метаданных нашего сервера Oracle. Мы создаем по одному файлу для каждого объекта, поэтому в результате получается не один огромный файл, а куча файлов. Для распознавания удаленного объекта мы удаляем все файлы перед повторным созданием дампа.
2. Копируем все файлы с сервера на клиентский компьютер.
3. Используя Netbeans, мы распознаем изменения и фиксируем изменения на сервере CVS (или проверяем различия ...). Здесь будет работать любое программное обеспечение-обработчик CVS, но мы уже использовали Netbeans для других целей. И Netbeans также позволяет создать задачу ant для вызова процесса Oracle, упомянутого на шаге 1, копируя файлы, упомянутые на шаге 2 ...

Вот самый важный запрос для шага 1:

SELECT object_type, object_name, 
  dbms_metadata.get_ddl(object_type, object_name) object_ddl FROM user_objects
WHERE OBJECT_TYPE in ('INDEX', 'TRIGGER', 'TABLE', 'VIEW', 'PACKAGE', 
  'FUNCTION', 'PROCEDURE', 'SYNONYM', 'TYPE')  
ORDER BY OBJECT_TYPE, OBJECT_NAME

Один файл на объектный подход помогает идентифицировать изменения. Если я добавлю поле в таблицу TTTT (конечно, не настоящее имя таблицы), то будет изменен только файл TABLE_TTTT.SQL.

И шаг 1, и шаг 3 - медленные процессы. (несколько минут для нескольких тысяч файлов)

Используя Контроль версий для Oracle, вы получаете многое из того, что ищете.

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

Затем новый SQL для создания объекта можно проверить в SVN или TFS (к сожалению, без поддержки CVS).

Инструмент платный, но имеет бесплатную 28-дневную пробную версию.