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

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

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

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

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

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

Автоматически переходите к ближайшему общему исправлению, используя методы таблицы db store down (), а затем переходите к последнему исправлению филиала.

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

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

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

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

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

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

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