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

Posted

技术标签:

【中文标题】PHP - 数据库模式:版本控制、分支、迁移【英文标题】:PHP - Database schema: version control, branching, migrations 【发布时间】:2011-02-05 12:38:31 【问题描述】:

我正在尝试提出(或找到)一个可重用的系统,用于 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 年后更新

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

相反,我使用构建脚本来:

    清空数据库, 创建架构, 添加已知的应用程序数据(真实内容),并且 添加夹具数据(开发内容)。

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

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

【问题讨论】:

(相关) davedevelopment.co.uk/2008/04/14/… 对此投反对票:“我在开发过程中通常放弃了迁移,因为它们不必要地复杂且容易出错。” - 我完全不能同意这种说法。如果有一件事情我可以避免多年来我所看到的所有技术进步,那就是数据库迁移。 YMMV。 【参考方案1】:

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

项目就在这里:

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

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

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

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

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

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

【讨论】:

谢谢@Billiam - 我会试试看

以上是关于PHP - 数据库模式:版本控制、分支、迁移的主要内容,如果未能解决你的问题,请参考以下文章

关系型数据库版本控制之(Flask SQLalchemy Alembic )

NodeJS 应用程序数据库版本控制和数据迁移

复杂分支系统中的数据库迁移

如何对支持不同依赖版本的多个发布分支进行版本控制?

EntityFramework Code First 模式下使用数据迁移

Flyway - 多个 git 分支上的 SQL 迁移脚本版本