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

Question

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

有许多 Rails 风格的迁移项目可用于 php。 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 表存储的 down() 方法自动向下合并到最近的共享补丁，然后向上合并到分支的最新补丁。

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

2 年后更新

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

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

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

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

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

Answer 1

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

项目就在这里：

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

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

它是 http://code.google.com/p/mysql-php-migrations/ 的一个分支，包含上述想法和其他一些小东西。

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

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

但是，仍然非常可以听到这种方法的潜在（甚至预期）陷阱。