我正在尝试在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（）方法。 更改分支时，将已运行的修补程序与目标分支中可用的修补程序进行比较。通过ID或散列确定运行补丁的db表与目标分支中的补丁之间最近的共享补丁（或最旧的差异）。还可以查找隐藏在两个分支之间的多个共享补丁下的新补丁或缺失补丁。
使用db table stored down（）方法自动合并到最近的共享补丁，然后合并到branche的最新补丁。
我的问题是： 这个系统是否过于疯狂和/或充满了影响发展的后果？我对数据库模式版本控制的经验仅限于PHP autopatch，这是一个仅限up（）的系统，需要具有顺序ID的文件名。
这是一篇旧帖子，但我想提一下，我在开发过程中一般都放弃了迁移，因为它们不必要地复杂且容易出错。
相反，我使用构建脚本：
更改分支或从其他开发人员接收更新时，使用一个命令完全重新加载数据库以进入已知状态。
生产服务器仍然需要数据库补丁，但无论如何都必须手动创建。
答案 0 :(得分：0)
好吧，我没有找到任何理由不继续前进。
这个项目就在这里：
http://github.com/Billiam/MySQL-PHP-AutoMigrations
需要一些爱（准确的评论，单元测试，实际的错误测试），但现在似乎对我有用。
包含上述想法以及其他一些小东西是http://code.google.com/p/mysql-php-migrations/的分支。
向下迁移是从保存在数据库中的方法向上移动，以便文件更改（如在分支之间切换时）不会影响向下迁移。 增加了两个功能：
仍然非常对这种方法的潜在（或甚至预期）缺陷持开放态度。