Схема PHP -базы данных: контроль версий, ветвление, миграции

Я пытаюсь придумать (или найти) многоразовую систему для управления версиями схемы базы данных в проектах php.

Для php доступно несколько проектов миграции в стиле Rails. http://code.google.com/p/mysql-php-migrations / является хорошим примером. Он использует временные метки для файлов миграции, что помогает при конфликтах между ветвями.

Общая проблема с такого рода системой: Когда ветвь разработки A извлечена, и вы хотите проверить ветвь B вместо этого, B могут быть новые файлы миграции. Это нормально, переход на более новый контент происходит прямо сейчас.

Если в ветви A есть более новые файлы миграции, вам потребуется выполнить миграцию вниз до ближайшего общего исправления. Если ветви A и B имеют существенно разные базы кода, вам, возможно, придется перейти еще дальше. Это может означать: Проверьте B, определите общий номер исправления, проверьте A, перейдите вниз к этому исправлению. Это должно быть сделано из A, так как фактические примененные исправления не являются доступно в B. Затем проверьте ветвь B и перейдите на новейший патч B. Снова обратный процесс при переходе от B к A.

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

Автоматическое объединение до ближайшего общего патча с использованием методов таблицы бд, сохраненной в down(), а затем объединение до последнего патча ветви.

Мой вопрос таков: Является ли эта система слишком сумасшедшей и/или чреватой последствиями, чтобы беспокоиться о ее развитии? Мой опыт работы с управление версиями схемы базы данных ограничено PHP autopatch, который является системой только для up(), требующей имен файлов с последовательными идентификаторами.

Обновление, 2 года спустя

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

Вместо этого я использую сценарии сборки для:

1. очистить базу данных,
2. создайте схему,
3. добавить известные данные приложения (реальные содержание), и
4. добавьте данные о приспособлениях (содержимое разработки).

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

Производственным серверам по-прежнему требуются исправления базы данных, но их все равно придется создавать вручную.