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

08-06-2019
|

Вопрос

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

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

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

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

Решение

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

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

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

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

Другие советы

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

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

Кроме того, у меня обычно есть таблица в базе данных — 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$, чтобы заморозить их.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DBMS_METADATA.GET_DDL
DBMS_METADATA.SET_TRANSFORM_PARAM
DBMS_METADATA.GET_GRANTED_DDL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Две рекомендации по книге:«Рефакторинг баз данных» Эмблера и Садалаге и «Гибкие методы работы с базами данных» Эмблера.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow