PHP - Схема базы данных: управление версиями, ветвление, миграции

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

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

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

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

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

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

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

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

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

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

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

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

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