PHP - 数据库模式：版本控制、分支、迁移

我正在尝试提出（或找到）一个可重用的系统，用于 php 项目中的数据库模式版本控制。

有许多可用于 php 的 Rails 风格的迁移项目。http://code.google.com/p/mysql-php-migrations/ http://code.google.com/p/mysql-php-migrations/就是一个很好的例子。它使用迁移文件的时间戳，这有助于解决分支之间的冲突。

此类系统的一般问题：当开发分支 A 被签出，并且您想要签出分支 B 时， B 可能有新的迁移文件。这很好，迁移到更新的内容是直接的。

如果分支 A 有较新的迁移文件，则需要向下迁移到最近的共享补丁。如果分支 A 和 B 的代码库显着不同，您可能需要进一步向下迁移。这可能意味着：签出B，确定共享补丁号，签出A，向下迁移到该补丁。这必须从 A 完成，因为实际应用的补丁在 B 中不可用。然后，签出分支 B，并迁移到最新的 B 补丁。从 B 到 A 时再次进行相反的过程。

提议的系统：向上迁移时，不只是存储补丁版本，而是在数据库中序列化整个补丁以供以后使用，尽管我可能只需要 down() 方法。 更改分支时，将已运行的补丁与目标分支中可用的补丁进行比较。通过 ID 或哈希确定运行补丁的数据库表与目标分支中的补丁之间最近的共享补丁（或者可能是最旧的差异）。还可以查找隐藏在两个分支之间的许多共享补丁下的新补丁或丢失补丁。

使用数据库表存储的 down() 方法自动向下合并到最近的共享补丁，然后向上合并到分支的最新补丁。

我的问题是：这个系统是否太疯狂和/或充满后果而懒得开发？我在数据库模式版本控制方面的经验仅限于 PHP autopatch，这是一个仅限 up() 的系统，需要具有顺序 ID 的文件名。

更新，2年后

这是一篇旧文章，但我想提一下，我在开发过程中通常放弃了迁移，因为它们不必要地复杂且容易出错。

相反，我使用构建脚本来：

1. 清除数据库，
2. 创建架构，
3. 添加已知的应用程序数据（真实内容），以及
4. 添加夹具数据（开发内容）。

当更改分支或接收其他开发人员的更新时，您可以使用一个命令完全重新加载数据库以达到已知状态。

生产服务器仍然需要数据库补丁，但无论如何都必须手动创建这些补丁。

好吧，我找不到任何理由不继续前进。

该项目如下：

http://github.com/Billiam/MySQL-PHP-AutoMigrations http://github.com/Billiam/MySQL-PHP-AutoMigrations

需要一些爱（准确的评论、单元测试、实际的错误测试），但现在似乎对我来说效果很好。

这是一个叉子http://code.google.com/p/mysql-php-migrations/ http://code.google.com/p/mysql-php-migrations/包括上面的想法，以及其他一些小东西。

向下迁移是通过向上迁移时保存在数据库中的方法完成的，因此文件更改（如在分支之间切换时的更改）不会影响向下迁移。 添加了两个功能：

• 一个神奇的“自动”功能，可以处理向下迁移到最旧的共享迁移，然后向上迁移到迁移目录中的最新迁移。
• “提议”功能显示 auto 将实际执行的操作。

Still very然而，对于这种方法潜在的（甚至预期的）陷阱持开放态度。