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

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

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

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

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

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

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

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

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

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

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

Взгляните на пакет 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). Как только вы освоитесь с этим, сравните схему между версией базы данных, управляемой исходным кодом, и производственной версией - одно дело. И одним щелчком мыши вы можете сгенерировать свой DDL для различий.

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

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

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

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

PLSQL Developer, a tool from All Arround Automations, has a plugin for repositories that works OK ( but not great) with Visual Source Safe.

From the web:

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

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

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

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

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

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

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

Мы довольно успешно использовали MS Team System Database Edition . Он более или менее легко интегрируется с системой управления версиями 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

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

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

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

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

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

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

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

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