sql - структуры - система контроля версий oracle




Существует ли система контроля версий для изменения структуры базы данных? (15)

PLSQL Developer, инструмент от All Arround Automations, имеет плагин для репозиториев, который работает нормально (но не очень) с Visual Source Safe.

Из Интернета:

Плагин управления версиями обеспечивает тесную интеграцию между IDE разработчика PL / SQL >> и любой системой управления версиями, которая поддерживает спецификацию интерфейса Microsoft SCC. >> Сюда входят наиболее популярные системы контроля версий, такие как Microsoft Visual SourceSafe, >> Merant PVCS и MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

Я часто сталкиваюсь со следующей проблемой.

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

Итак, я делаю толчок к работающей системе и получаю большую, очевидную ошибку, что NewColumnX нет, тьфу.

Независимо от того, что это не может быть наилучшей практикой в ​​этой ситуации, существует ли система контроля версий для баз данных? Я не забочусь о конкретной технологии базы данных. Я просто хочу знать, если таковой существует. Если это случится для работы с MS SQL Server, то отлично.


Redgate имеет продукт под названием SQL Source Control . Он интегрируется с TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce и Git.


Большинство механизмов баз данных должны поддерживать дамп вашей базы данных в файл. Во всяком случае, я знаю, что MySQL. Это будет просто текстовый файл, так что вы можете отправить его в Subversion, или что вы используете. Было бы легко запустить diff для файлов тоже.


В Ruby on Rails есть концепция migration - быстрый скрипт для изменения базы данных.

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

Чтобы выполнить миграцию вверх , вы запускаете команду db: migrate, которая просматривает вашу версию и применяет необходимые сценарии. Вы можете перейти вниз аналогичным образом.

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


Взгляните на пакет оракула DBMS_METADATA.

В частности, следующие методы особенно полезны:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

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

Не уверен, что есть что-то такое простое для MSSQL.


Две рекомендации книги: «Рефакторинг баз данных» от Ambler и Sadalage и «Agile Database Techniques» от Ambler.

Кто-то упомянул Rails Migrations. Я думаю, что они отлично работают, даже за пределами приложений Rails. Я использовал их в приложении ASP с SQL Server, которое мы перешли на Rails. Вы проверяете сами скрипты миграции в VCS. Вот пост прагматичного Дэйва Томаса на эту тему.


Если вы используете SQL Server, было бы трудно победить Data Dude (он же Database Edition Visual Studio). Как только вы это освоите, сравнение схемы между вашей исходной управляемой версией базы данных и версией в рабочей среде будет проще простого. И одним щелчком мыши вы можете создать свой diff DDL.

На MSDN есть обучающее video которое очень полезно.

Я знаю о DBMS_METADATA и Toad, но если бы кто-то мог придумать Data Dude для Oracle, тогда жизнь была бы действительно сладкой.


Интересно, что никто не упомянул инструмент с открытым исходным кодом liquibase который основан на Java и должен работать почти для каждой базы данных, поддерживающей jdbc. По сравнению с рельсами он использует xml вместо ruby ​​для выполнения изменений схемы. Хотя я не люблю xml для языков, специфичных для предметной области, очень классное преимущество xml состоит в том, что liquibase знает, как откатить некоторые операции, такие как

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Так что вам не нужно справляться с этим самостоятельно

Чистые операторы SQL или импорт данных также поддерживаются.


Сделайте ваши первоначальные операторы создания таблицы в контроллере версий, затем добавьте операторы alter table, но никогда не редактируйте файлы, просто добавляйте файлы с идеальным последовательным именем или даже как «набор изменений», чтобы вы могли найти все изменения для конкретного развертывания.

Самая трудная часть, которую я вижу, это отслеживание зависимостей, например, для конкретной таблицы развертывания B может потребоваться обновление до таблицы A.


Существует PHP5 "среда миграции базы данных", которая называется Ruckusing. Я не использовал его, но examples показывают идею: если вы используете язык для создания базы данных по мере необходимости, вам нужно только отслеживать исходные файлы.


Я делал это время от времени - управлял (или пытался управлять) версиями схемы. Лучшие подходы зависят от инструментов, которые у вас есть. Если вы сможете приобрести инструмент Quest Software «Schema Manager», вы будете в хорошей форме. У Oracle есть собственный, более низкий инструмент, который также называется «Диспетчер схем» (много смущает?), Который я не рекомендую.

Без автоматического инструмента (см. Другие комментарии здесь о Data Dude) вы будете напрямую использовать скрипты и файлы DDL. Выберите подход, задокументируйте его и строго следуйте ему. Мне нравится иметь возможность заново создавать базу данных в любой момент, поэтому я предпочитаю иметь полный экспорт DDL всей базы данных (если я администратор баз данных) или схемы разработчика (если я в продукте) режим разработки).


Я настоятельно рекомендую дельта SQL . Я просто использую его для генерации сценариев diff, когда я закончу кодировать свою функцию, и проверяю эти сценарии в своем инструменте управления версиями (Mercurial :))

У них есть версия SQL-сервера и Oracle.


Я пишу свои сценарии выпуска БД параллельно с кодированием и храню сценарии выпуска в разделе, посвященном конкретному проекту, в SS. Если я внесу изменение в код, который требует изменения базы данных, я одновременно обновлю скрипт выпуска. Перед выпуском я запускаю скрипт выпуска на чистой базе данных разработчика (копируемую структуру с производства) и выполняю на нем окончательное тестирование.


Инструменты визуализации Microsoft SQL Server можно использовать в Visual Studio для генерации сценариев для объектов базы данных в рамках проекта SQL Server. Затем вы можете добавить сценарии в систему управления версиями, используя интеграцию системы управления версиями, встроенную в Visual Studio. Кроме того, проекты SQL Server позволяют проверять объекты базы данных с помощью компилятора и генерировать сценарии развертывания для обновления существующей базы данных или создания новой.


ER Studio позволяет вам обратить схему вашей базы данных в инструмент, а затем сравнить ее с действующими базами данных.

Пример: переверните вашу схему разработки в ER Studio - сравните ее с производственной, и она перечислит все различия. Он может записать изменения или просто протолкнуть их автоматически.

Получив схему в ER Studio, вы можете либо сохранить сценарий создания, либо сохранить его как собственный двоичный файл и сохранить его в системе управления версиями. Если вы когда-нибудь захотите вернуться к прошлой версии схемы, просто проверьте ее и отправьте на свою платформу БД.





version-control