我正试图在php项目中提出（或找到）可重用的数据库模式版本控制系统 .
有许多可用于PHP的Rails风格的迁移项目 . http://code.google.com/p/mysql-php-migrations/就是一个很好的例子 . 它使用时间戳作为迁移文件，这有助于分支之间的冲突 .
General problem with this kind of system: 当签出开发分支A并且您想要检出分支B时，B可能有新的迁移文件 . 这很好，迁移到更新的内容是直截了当的 .
如果分支A具有较新的迁移文件，则需要向下迁移到最近的共享修补程序 . 如果分支A和B具有明显不同的代码库，则可能必须进一步向下迁移 . 这可能意味着：签出B，确定共享补丁号，签出A，向下迁移到此补丁 . 这必须从A完成，因为实际应用的补丁在B中不可用 . 然后，结帐分支B，并迁移到最新的B补丁 . 从B到A时再次反向处理 .
Proposed system: 向上迁移时，不是仅存储补丁版本，而是将整个补丁序列化到数据库中供以后使用，尽管我可能只需要down（）方法 . 更改分支时，将已运行的修补程序与目标分支中可用的修补程序进行比较 . 通过ID或散列确定运行补丁的db表与目标分支中的补丁之间最近的共享补丁（或最旧的差异） . 还可以查找隐藏在两个分支之间的多个共享补丁下的新补丁或缺失补丁 .
使用db表存储的down（）方法自动合并到最近的共享补丁，然后合并到branche的最新补丁 .
My question is: 这个系统是否过于疯狂和/或充满了影响开发的后果？我对数据库模式版本控制的经验仅限于PHP autopatch，这是一个仅限up（）的系统，需要带有顺序ID的文件名 .
更新，2年后
这是一篇很老的帖子，但我想提一下，我在开发过程中一般都放弃了迁移，因为它们不必要地复杂且容易出错 .
相反，我使用构建脚本：
-
清除数据库，
-
创建架构，
-
添加已知的应用程序数据（真实内容），和
-
添加夹具数据（开发内容） .
更改分支或从其他开发人员接收更新时，使用一个命令完全重新加载数据库以进入已知状态 .
生产环境 服务器仍然需要数据库补丁，但无论如何都必须手动创建 .
1 回答
好吧，我没有找到任何理由不继续前进 .
像这样的项目在这里：
http://github.com/Billiam/MySQL-PHP-AutoMigrations
需要一些爱（准确的评论，单元测试，实际的错误测试），但现在似乎对我有用 .
这是http://code.google.com/p/mysql-php-migrations/的一个分支，包括上面的想法，以及其他一些小东西 .
向下迁移是从保存在数据库中的方法向上迁移，以便文件更改（如在分支之间切换时）不会影响向下迁移 . 增加了两个功能：
一个神奇的'auto'函数，用于处理迁移到最早的共享迁移，然后迁移到迁移目录中的最新迁移 .
'propose'函数显示auto实际执行的操作 .
然而，仍然可以通过这种方法听到潜在的（甚至是预期的）陷阱 .