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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В MSDN есть инструкция видео, которая очень полезна.

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

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

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

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

From the web:

The Version Control Plug-In provides a tight integration between the PL/SQL Developer IDE >>and any Version Control System that supports the Microsoft SCC Interface Specification. >>This includes most popular Version Control Systems such as Microsoft Visual SourceSafe, >>Merant PVCS and MKS Source Integrity.

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

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

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

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

Рекомендации по двум книгам: «Рефакторинг баз данных» Эмблера и Садаладжа и «Методы гибкой разработки баз данных» Эмблера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To achieve a good database change management practice, we need to identify a few key goals. Thus, the MyBatis Schema Migration System (or MyBatis Migrations for short) seeks to:

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

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

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