Контроль источника базы данных с помощью Oracle

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

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

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

Это непросто. Я загрузил много демо, которые так или иначе терпят неудачу.

РЕДАКТИРОВАТЬ: я бы не прочь альтернативы aproaches при условии, что они позволяют нам проверять рабочую систему на нашу версию DATABASE STRUCTURE AND OBJECTS + DATA в пакетном режиме.

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

Это может быть не так гладко, как обнаружение различий, однако мы используем простой файл сборки ant. В нашем текущем CVS-ветке у нас будет "базовый" код базы данных, который разбивается на ddl для таблиц и триггеров и т.д. У нас также будет дельта-папка, разбитая таким же образом. Начиная с нуля, вы можете запустить "base" + "delta" и получить текущее состояние базы данных. Когда вы приступите к производству, вы просто запустите сборку "delta" и сделайте это. Эта модель не работает uber-well, если у вас есть огромная схема, и вы быстро меняете ее. (Примечание. По крайней мере, среди объектов базы данных, таких как таблицы, индексы и т.д. Для пакетов, процедур, функций и триггеров он работает хорошо.) Вот пример задачи 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>

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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