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

Bil*_*iam 13 php database migration version-control schema

我正试图在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表存储的down()方法自动合并到最近的共享补丁,然后合并到branche的最新补丁.

我的问题是: 这个系统是否过于疯狂和/或充满了影响发展的后果?我对数据库模式版本控制的经验仅限于PHP autopatch,这是一个仅限up()的系统,需要带有顺序ID的文件名.

2年后更新

这是一篇很老的帖子,但我想提一下,我在开发过程中一般都放弃了迁移,因为它们不必要地复杂且容易出错.

相反,我使用构建脚本:

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

更改分支或从其他开发人员接收更新时,使用一个命令完全重新加载数据库以进入已知状态.

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

Bil*_*iam 0

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

该项目如下:

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

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

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

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

  • 一个神奇的“自动”功能,可以处理向下迁移到最旧的共享迁移,然后向上迁移到迁移目录中的最新迁移。
  • 'propose' 函数显示 auto 实际会做什么。

然而,仍然对这种方法潜在的(甚至预期的)陷阱持非常开放的态度。