Механизмы отслеживания изменений схемы БД [закрыты]

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

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

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

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

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

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

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

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

Однако будьте осторожны при вставке запросов от phpMyAdmin! Эти сгенерированные запросы обычно включают имя базы данных, которое вам определенно не нужно, так как это нарушит ваши сценарии! Что-то вроде СОЗДАНИЯ ТАБЛИЦЫ mydb.newtable(...) произойдет сбой, если база данных в системе не называется mydb. Мы создали крючок SVN с предварительным комментарием, который запретит файлы .sql, содержащие строку mydb, что является верным признаком того, что кто-то скопировал/вставил из phpMyAdmin без надлежащей проверки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Http://subsonicproject.com/

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

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

База данных

Сценарии изменения

0.Предварительное развертывание.sql

1.schemachanges.sql

2.Изменения данных.sql

3. Разрешения.sql

Создание сценариев

Спроки

Функции

Представления

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

1.Предварительное развертывание.sql

2.schemachanges.sql

Содержимое папки "Создать сценарии"

2.Изменения данных.sql

3. Разрешения.sql

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

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

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

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

Итак, в нашем программном обеспечении мы имеем что-то вроде этого:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Попробуйте 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 на диске. Это хорошо подходит для большинства задач миграции схем.