Механизмы отслеживания изменений схемы DB

В мире Rails существует концепция миграций, скриптов, в которых изменения в базе данных вносятся в Ruby, а не в специфичный для базы данных аромат SQL. Ваш код миграции Ruby в конечном итоге преобразуется в код DDL, специфичный для вашей текущей базы данных; это делает переключение платформ баз данных очень легким.

Для каждого изменения, внесенного в базу данных, вы пишете новую миграцию. Миграции обычно имеют два метода: метод "up", в котором применяются изменения, и метод "down", в котором изменения отменяются. Одна команда обновляет базу данных, а также может использоваться для приведения базы данных к определенной версии схемы. В Rails миграции хранятся в своем собственном каталоге в каталоге проекта и регистрируются в системе управления версиями, как и любой другой код проекта.

Это руководство Oracle по Rails миграциям довольно хорошо описывает миграции.

Разработчики, использующие другие языки, изучили миграцию и реализовали свои собственные языковые версии. Я знаю о Ruckusing , системе миграции PHP, которая моделируется после миграции Rails; это может быть то, что вы ищете.

Мы используем нечто похожее на bcwoord, чтобы синхронизировать наши схемы баз данных между 5 различными установками (производственными, промежуточными и несколькими установками разработки) и создавать резервные копии в системе управления версиями, и это работает довольно хорошо. Я немного уточню:

Для синхронизации структур баз данных, у нас есть один сценарий, update.php, и количество файлов, пронумерованных 1.sql, 2.sql, 3.sql, и т. д. Скрипт использует одну дополнительную таблицу для хранения текущего номера версии базы данных. Файлы N.sql создаются вручную, чтобы перейти от версии (N-1) к версии N базы данных.

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

Скрипт обновления работает следующим образом:

• Подключитесь к базе данных.
• Сделайте резервную копию текущей базы данных (потому что все пойдет не так) [mysqldump].
• Создайте бухгалтерскую таблицу (называемую _meta), если она не существует.
• Считывание текущего значения VERSION из таблицы _meta. Предположим 0, если не найден.
• Для всех файлов .sql, пронумерованных выше, чем VERSION, выполните их по порядку
• Если один из файлов выдал ошибку: откат к резервной копии
• В противном случае обновите версию в таблице бухгалтерского учета до самого высокого значения .sql выполненного файла.

Все идет в систему управления версиями, и каждая установка имеет скрипт для обновления до последней версии с помощью одного выполнения скрипта (вызов update.php с соответствующим паролем базы данных и т. д.). Мы SVN обновляем промежуточные и производственные среды с помощью скрипта, который автоматически вызывает скрипт обновления базы данных, поэтому обновление кода идет вместе с необходимыми обновлениями базы данных.

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

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

Однако будьте осторожны при вставке запросов из phpMyAdmin! Эти генерируемые запросы обычно включают имя базы данных, которое вы определенно не хотите, так как это нарушит ваши скрипты! Что-то вроде CREATE TABLE mydb . newtable (...) произойдет сбой, если база данных в системе не называется mydb. Мы создали предварительный комментарий SVN Хук, который будет запрещать .sql файлы, содержащие строку mydb , что является верным признаком того, что кто-то скопировал/вставил из phpMyAdmin без надлежащей проверки.

Моя команда выполняет сценарии всех изменений базы данных и фиксирует эти сценарии в SVN вместе с каждым выпуском приложения. Это позволяет производить инкрементные изменения базы данных без потери каких-либо данных.

Чтобы перейти от одного выпуска к другому, вам просто нужно запустить набор сценариев изменений, и ваша база данных up-to-date, и у вас все еще есть все ваши данные. Возможно, это не самый простой метод, но он определенно эффективен.

Если вы все еще ищете решения : мы предлагаем инструмент под названием neXtep designer. Это среда разработки баз данных, с помощью которой вы можете поставить всю свою базу данных под контроль версий. Вы работаете в репозитории с управлением версиями, где можно отслеживать каждое изменение.

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

Тогда у вас есть много вариантов : вы можете взять эти сценарии и поместить их в свой SVN вместе с кодом приложения, чтобы он был развернут вашим существующим механизмом. Другой вариант-использовать механизм доставки neXtep: скрипты экспортируются в нечто, называемое "delivery package" (SQL скрипта + XML дескриптор), и установщик может понять этот пакет и развернуть его на целевом сервере, обеспечивая при этом согласованность strcutural, проверку зависимостей, регистрацию установленной версии и т. д.

Продукт является GPL и основан на Eclipse, поэтому он работает на Linux, Mac и windows. Он также поддерживает Oracle, Mysql и Postgresql в данный момент (поддержка DB2 уже в пути). Взгляните на wiki, где вы найдете более подробную информацию : http://www.nextep-softwares.com/wiki

Проблема здесь заключается в том, что разработчикам действительно легко создавать собственные локальные изменения в системе управления версиями, чтобы поделиться ими с командой. Я сталкивался с этой проблемой в течение многих лет и был вдохновлен функциональностью Visual Studio для профессионалов баз данных. Если вам нужен инструмент с открытым исходным кодом с такими же функциями, попробуйте следующее: http://dbsourcetools.codeplex.com / Have fun, - Натан.

Сбросьте схему в файл и добавьте ее в систему управления версиями. Тогда простой diff покажет вам, что изменилось.

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

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

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

У К. Скотта Аллена есть приличная статья или две по версионированию схем, в которых используется концепция инкрементных сценариев обновления/миграции, упоминаемая в других ответах здесь; см. http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

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

Затем зафиксируйте сценарий в системе управления версиями вместе с кодом, который работает на нем. Если вам нужно изменить схему вместе с кодом, сценарий может быть возвращен вместе с кодом, который требует изменения схемы. Затем диффы в скрипте будут указывать на диффы при изменении схемы.

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

Если вы используете C#,, посмотрите на Subsonic, очень полезный инструмент ORM, но также генерирует сценарий sql для воссоздания ваших данных схемы and\or. Затем эти сценарии можно поместить в систему управления версиями.

http://subsonicproject.com/

Мы используем очень простое, но все же эффективное решение.

Для новых установок у нас есть файл metadata.sql в репозитории, который содержит всю схему DB, а затем в процессе сборки мы используем этот файл для создания базы данных.

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

Поэтому в нашем программном обеспечении мы имеем нечто подобное:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Этот код проверит, находится ли база данных в версии 1 (которая хранится в таблице, созданной автоматически), если она устарела, то команда будет выполнена.

Чтобы обновить metadata.sql в репозитории, мы запускаем это обновление локально, а затем извлекаем полные метаданные базы данных.

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

Кроме того, мы не поддерживаем понижение рейтинга, но это по замыслу, если что-то сломается при обновлении, мы восстановили предыдущую версию и исправим обновление, прежде чем пытаться снова.

Я использовал следующую структуру проекта базы данных в Visual Studio для нескольких проектов, и она работала довольно хорошо:

База данных

сценарий изменения

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Создание Скриптов

Хранимые процедуры

Функции

Просмотры

Затем наша система сборки обновляет базу данных от одной версии до следующей, выполняя сценарии в следующем порядке:

1.PreDeploy.sql

2.SchemaChanges.sql

Содержание создание скриптов папку

2.DataChanges.sql

3.Permissions.sql

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

Я создаю папки с именами версий сборки и помещаю туда скрипты обновления и понижения. Например, у вас могут быть следующие папки: 1.0.0, 1.0.1 и 1.0.2. Каждый из них содержит скрипт, который позволяет вам обновить или понизить вашу базу данных между версиями.

Если клиент или клиент позвонит вам с проблемой с версией 1.0.1, а вы используете 1.0.2, возвращение базы данных к его версии не будет проблемой.

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

Точно так же, как сказал Джоуи, если вы находитесь в мире Rails, используйте миграции. :)

Toad для MySQL имеет функцию сравнения схем, которая позволяет синхронизировать 2 базы данных. Это лучший инструмент, который я использовал до сих пор.

Имхо миграции действительно имеют огромную проблему:

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

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

Мне нравится, как Yii обрабатывает миграции баз данных. Миграция-это в основном сценарий PHP, реализующий CDbMigration . CDbMigration определяет метод up , содержащий логику миграции. Также можно реализовать метод down для поддержки обратного хода миграции. Кроме того, safeUp или safeDown можно использовать, чтобы убедиться, что миграция выполняется в контексте транзакции.

Инструмент командной строки Yii yiic содержит поддержку для создания и выполнения миграций. Миграции могут быть применены или отменены, либо по одному, либо в пакетном режиме. Создание миграции приводит к коду для класса PHP, реализующего CDbMigration, с уникальным именем, основанным на timestamp и имени миграции, указанном пользователем. Все миграции, ранее примененные к базе данных, хранятся в таблице миграции.

Дополнительные сведения см. В статье перенос базы данных из руководства.

Для моего текущего проекта PHP мы используем идею rails миграций, и у нас есть каталог миграций, в котором мы храним название файлов "migration_XX.sql", где XX-номер миграции. В настоящее время эти файлы создаются вручную по мере обновления, но их создание может быть легко изменено.

Затем у нас есть скрипт под названием "Migration_watcher", который, как и в pre-alpha, в настоящее время запускается при каждой загрузке страницы и проверяет, есть ли новый файл migration_XX.sql, где XX больше, чем текущая версия миграции. Если это так, то он запускает все файлы migration_XX.sql до самого большого числа против базы данных и вуаля! изменения схемы происходят автоматически.

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

Я бы рекомендовал использовать Ant (кросс-платформенный) для стороны "scripting" (поскольку он может практически разговаривать с любой БД через jdbc) и Subversion для исходного репозитория. Ant перед внесением изменений приведет вас к "back up" вашей БД в локальные файлы. 1. резервное копирование существующей схемы БД в файл через Ant 2. контроля версий SVN-репозиторий через Ant 3. отправка новых операторов sql в БД через Ant

Попробуйте db-deploy-в основном инструмент Java, но также работает и с php.

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

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