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

Я немного старая школа, потому что я использую исходные файлы для создания базы данных. На самом деле есть 2 файла - project-database.sql и project-updates.sql - первый для схемы и постоянных данных, а второй для модификаций. Конечно, оба находятся под контролем источника.

Когда база данных изменяется, я сначала обновляю основную схему в файле project-database.sql, а затем копирую соответствующую информацию в project-updates.sql, например, инструкции ALTER TABLE. Затем я могу применить обновления к базе данных разработки, протестировать, итерации до тех пор, пока все будет хорошо. Затем проверьте файлы, повторите проверку и примените к производству.

Кроме того, у меня обычно есть таблица в db-Config - например:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Затем добавьте в раздел обновления следующее:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Изменяется только db_version, когда база данных воссоздана, а db_revision дает мне указание, насколько удаленная база находится вне базовой линии.

Я мог бы хранить обновления в своих отдельных файлах, но я решил объединить их все вместе и использовать cut & paste для извлечения соответствующих разделов. Немного больше домашнего хозяйства в порядке, то есть удалите ':' из $Revision 1.1 $, чтобы заморозить их.

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

MyBatis (ранее iBatis) имеет миграцию схемы, инструмент для использования в командной строке. Он написан в java, но может использоваться с любым проектом.

Чтобы добиться хорошей практики управления изменениями базы данных, нам необходимо определить несколько ключевых целей. Таким образом, MyBatis Schema Migration System (или MyBatis Migrations для краткости) ищет:

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

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

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

Таким образом, вам не нужно обращаться с этим собственным

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

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

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

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

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

Вот очень полезный учебный видео на MSDN.

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

Взгляните на пакет Oracle DBMS_METADATA.

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

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

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

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

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

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

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

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

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

Модуль управления версиями обеспечивает тесную интеграцию между IDE PL/SQL Developer ID и любой системой управления версиями, которая поддерживает спецификацию интерфейса SCC. → Это включает в себя самые популярные системы управления версиями, такие как Microsoft Visual SourceSafe, → Merant PVCS и целостность источника MKS.

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

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

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

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

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

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

Как только у вас есть схема в ER Studio, вы можете либо сохранить создание script, либо сохранить его в качестве запатентованного двоичного файла и сохранить его в контроле версий. Если вы когда-нибудь захотите вернуться к предыдущей версии схемы, просто проверьте ее и нажмите на свою платформу db.

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

Вы можете использовать Microsoft SQL Server Data Tools в visual studio для создания сценариев для объектов базы данных как часть проекта SQL Server. Затем вы можете добавить сценарии в исходный элемент управления, используя интеграцию управления версиями, встроенную в визуальную студию. Кроме того, проекты SQL Server позволяют проверять объекты базы данных с помощью компилятора и создавать сценарии развертывания для обновления существующей базы данных или создания новой.

Schema Compare for Oracle - это инструмент, специально предназначенный для переноса изменений из нашей базы данных Oracle в другую. Пожалуйста, перейдите по ссылке ниже для ссылки для загрузки, где вы сможете использовать программное обеспечение для полнофункциональной пробной версии.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Мы использовали MS Team System Database Edition с довольно хорошим успехом. Он легко интегрируется с управлением версиями TFS и Visual Studio более или менее и позволяет нам легко управлять хранимыми процессами, представлениями и т.д. Разрешение конфликтов может быть больно, но история версий завершена. После этого миграция в QA и производство чрезвычайно просты.

Справедливости ради стоит сказать, что это продукт версии 1.0, хотя и не без нескольких проблем.

Я бы порекомендовал один из двух подходов. Сначала инвестируйте в PowerDesigner из Sybase. Enterprise Edition. Это позволяет вам создавать физические данные и многое другое. Но он поставляется с репозиторием, который позволяет вам проверять свои модели. Каждая новая проверка может быть новой версией, она может сравнивать любую версию с любой другой версией и даже с тем, что находится в вашей базе данных в то время. Затем он представит список всех различий и спросит, что должно быть перенесено... и затем он создает script для этого. Его не дешево, но его сделка в два раза выше цены и ее ROI составляет около 6 месяцев.

Другая идея - включить DDL-аудит (работает в Oracle). Это создаст таблицу с каждым изменением, которое вы сделаете. Если вы запрашиваете изменения с временной отметки, которую вы в последний раз перенесли, изменения в базе данных в prod прямо сейчас, у вас будет упорядоченный список всего, что вы сделали. Несколько статей, где можно исключить изменения с нулевой суммой, например create table foo; затем следует таблица drop foo; и вы можете легко создать мод script. Зачем хранить изменения в вики, что вдвое больше. Пусть база данных отслеживает их для вас.

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

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

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