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

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

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

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

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

Я немного старомоден в том, что использую исходные файлы для создания базы данных. На самом деле существует 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 $, чтобы заморозить их.

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

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

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

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

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

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

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

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

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

Они оба имеют версию SQL server & Oracle.

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

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

Есть обучающее видео на MSDN, которое очень полезно.

Я знаю о СУБД_МЕТАДАТА и Toad, но если бы кто-то мог придумать чувака данных для Oracle, то жизнь была бы действительно сладкой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Две книги рекомендации: "Refactoring Databases" по Амблер и Sadalage и "Agile Database Techniques" по Амблер.

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