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

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

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

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

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

В Ruby on 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дает мне представление о том , как далеко дБ от базовой линии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я делал это время от времени - управлял (или пытался управлять) версиями схемы. Лучшие подходы зависят от имеющихся у вас инструментов. Если вы сможете получить инструмент Quest Software "Schema Manager", вы будете в хорошей форме. У 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 - сравните ее с производственной, и в ней будут перечислены все различия. Он может записать изменения или просто протолкнуть их автоматически.

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

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

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

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

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

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

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

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

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

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

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

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