Управление исходным кодом базы данных с Oracle

Question

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

Основные условия:

• Работает для Oracle 9R2
• Человек читается, поэтому мы можем использовать diff, чтобы увидеть различия. (файлы .dmp не читаются)
• Все таблицы в пакете. У нас более 200 столов.
• Хранит ОБА СТРУКТУРУ И ДАННЫХ
• Поддерживаются типы CLOB и RAW.
• В нем хранятся процедуры, пакеты и их тела, функции, таблицы, представления, индексы, ограничения, секреты и синонимы.
• Его можно превратить в исполняемый скрипт, чтобы перестроить базу данных на чистый компьютер.
• Не ограничивается действительно небольшими базами данных (поддерживает не менее 200 000 строк)

Это не легко. Я скачал много демонстраций, которые так или иначе не срабатывают.

РЕДАКТИРОВАТЬ : Я не возражаю против альтернативных подходов при условии, что они позволяют нам проверять работающую систему на соответствие нашей версии СТРУКТУРА И ОБЪЕКТЫ БАЗЫ ДАННЫХ + ДАННЫЕ в пакетном режиме.

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

EDIT : Чтобы лучше понять проблему, скажем, что некоторые пользователи могут иногда вносить изменения в данные конфигурации в производственной среде. Или разработчики могут создать новое поле или изменить представление без уведомления в ветке выпуска. Мне нужно знать об этих изменениях, иначе будет сложно объединить изменения в производство.

Answer 1

Так много людей пытаются делать подобные вещи (схемы различий). Мое мнение

• Исходный код входит в инструмент управления версиями (Subversion, CSV, GIT, Perforce ...). Относитесь к нему так, как если бы это был код Java или C, на самом деле он ничем не отличается. У вас должен быть процесс установки, который проверяет его и применяет к базе данных.
• DDL - ИСТОЧНИК КОД. Это также входит в инструмент контроля версий.
• Данные - это серая область - таблицы поиска, возможно, должны быть в инструменте контроля версий. Данные, сгенерированные приложением, конечно, не должны.

В настоящее время я работаю над созданием сценариев миграции, аналогичных миграциям Ruby on Rails. Поместите свой DDL в сценарии и запустите их для перемещения базы данных между версиями. Сгруппируйте изменения для выпуска в один файл или набор файлов. Затем у вас есть скрипт, который перемещает ваше приложение с версии x на версию y.

Одна вещь, которую я никогда больше не делаю (и я делал это до тех пор, пока не научился лучше), это использование любых инструментов с графическим интерфейсом для создания объектов базы данных в моей среде разработки. Написание сценариев DDL с первого дня - они вам понадобятся в любом случае для продвижения кода для тестирования, производства и т. Д. Я видел очень много людей, которые используют GUI для создания всех объектов и наступления времени выпуска, и существует попытка произвести скраббл. скрипты для правильного создания / переноса схемы, которые часто не тестируются и дают сбой!

У каждого будет свое предпочтение тому, как это сделать, но я видел, что многое из этого было сделано плохо за те годы, которые сформировали мое мнение выше.

Answer 2

Я использую PL / SQL developer с подключаемым модулем VCS, который интегрируется в Team Foundation Server, но поддерживает только объекты базы данных, а не сами данные, которые в любом случае обычно остаются вне контроля исходного кода.

Вот ссылка: http://www.allroundautomations.com/bodyplsqldev.html

Answer 3

Oracle SQL Developer имеет функцию «Экспорт базы данных». Он может создать один файл, который содержит все DDL и данные.

Answer 4

Попробуйте RedGate Source Control для Oracle . Я никогда не пробовал версию Oracle, но версия MSSQL действительно хороша.

Answer 5

Хотя это может быть дорого, такой инструмент, как TOAD для Oracle , может быть идеальным для решения такого рода проблем.

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

На моей последней работе у меня были сценарии NAnt, которые восстанавливали тестовые базы данных, запускали все необходимые сценарии обновления в зависимости от версии базы данных, а затем выводили конечный результат в DDL и DML. Я бы сделал то же самое для пустой базы данных (чтобы создать ее с нуля), а затем сравнить результаты. Если бы они были существенно различны (программа дампа не была идеальной), я мог бы сразу сказать, какие изменения необходимо внести в обновление / создание DDL и DML. Хотя я использовал инструменты сравнения баз данных, такие как TOAD, они были не так полезны, как рукописный SQL, когда мне нужно было создавать общие сценарии для массирования данных. (Машинный код может быть очень хрупким.)

Answer 6

Не пытайтесь анализировать данные. Просто напишите триггер для хранения того, что вы хотите получить при изменении данных.

Answer 7

Вы пробовали Oracle Workspace Manager ? Не то чтобы у меня был какой-либо опыт работы с ним в производственной базе данных, но я нашел несколько игрушечных экспериментов с ним многообещающими.

Answer 8

Я думаю, что это случай,

• Вы пытаетесь решить проблему
• Вы придумали решение
• Вы не знаете, как реализовать решение
• так что теперь вы просите помощи о том, как реализовать решение

Лучший способ получить помощь,

• Скажите нам, в чем проблема
• попросить идеи для решения проблемы
• выбери лучшее решение

Я не могу сказать, в чем заключается проблема, которую вы пытаетесь решить. Иногда это очевидно из вопроса, этот, конечно, нет. Но я могу вам сказать, что это «решение» превратится в собственный кошмар обслуживания. Если вы думаете, что разрабатывать базу данных и приложение, которое ее использует, сложно. Эта идея создания версий всей базы данных в удобочитаемой для человека форме - не что иное, как безумие.

Answer 9

Это может быть не так гладко, как обнаружение различий, однако мы используем простой файл сборки муравья. В нашей текущей ветке CVS у нас будет «базовый» код базы данных, разбитый на ddl для таблиц, триггеров и тому подобного. У нас также будет папка delta, разбитая таким же образом. Начиная с нуля, вы можете запустить «base» + «delta» и получить текущее состояние базы данных. Когда вы отправитесь в производство, вы просто запустите сборку «delta» и все будет готово. Эта модель работает не очень хорошо, если у вас огромная схема и вы быстро ее меняете. (Примечание: по крайней мере, среди объектов базы данных, таких как таблицы, индексы и т. П. Для пакетов, процедур, функций и триггеров это работает хорошо.) Вот пример задачи ant:

    <target name="buildTables" description="Build Tables with primary keys and sequences">
<sql driver="${conn.jdbc.driver}" password="${conn.user.password}"
    url="${conn.jdbc.url}" userid="${conn.user.name}"
    classpath="${app.base}/lib/${jdbc.jar.name}">
    <fileset dir="${db.dir}/ddl">
        <include name="*.sql"/>
    </fileset>
</sql>
</target>