PHP - 数据库模式：版本控制，分支，迁移 [英] PHP - Database schema: version control, branching, migrations

问题描述

我尝试在php项目中想出一个可重用的数据库模式版本控制系统。项目可用于php。 http://code.google.com/p/mysql-php-migrations/是一个很好的例子。

此类系统的常见问题：
当开发分支A被检出，而你想检查分支B，而
B可能有新的迁移文件。

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

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

使用db表自动合并到最近的共享补丁存储down（）方法，然后合并到分支的最新补丁。

我的问题是：疯狂和/或充满后果打扰发展？

更新，2年后

这是一个老帖子，但我想提一下，我在开发期间一般放弃了迁移，因为它们不必要的复杂和容易出错。

而是使用构建脚本：

1. 清除数据库，


2. 创建架构，


3. 添加已知应用程序数据（实际内容），


4. 添加夹具数据（开发内容）。

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

生产服务器仍然需要数据库修补程序，但这些修补程序仍然需要手动创建。

解决方案

好，我找不到任何理由不向前迈进。

这个项目， / p>

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

需要一些爱（准确的评论，单元测试，实际的bug测试），但似乎对我来说工作良好

这是 http://code.google.com/p/mysql-php-migrations/ 以包含上述想法和其他一些小东西。

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

• 一个魔法自动函数，可以迁移到最早的共享迁移，

$ b

仍然非常可以接受此方法的潜在（甚至预期）陷阱。

I'm trying to come up with (or find) a reusable system for database schema versioning in php projects.

There are a number of Rails-style migration projects available for php. http://code.google.com/p/mysql-php-migrations/ is a good example. It uses timestamps for migration files, which helps with conflicts between branches.

General problem with this kind of system: When development branch A is checked out, and you want to check out branch B instead, B may have new migration files. This is fine, migrating to newer content is straight forward.

If branch A has newer migration files, you would need to migrate downwards to the nearest shared patch. If branch A and B have significantly different code bases, you may have to migrate down even further. This may mean: Check out B, determine shared patch number, check out A, migrate downwards to this patch. This must be done from A since the actual applied patches are not available in B. Then, checkout branch B, and migrate to newest B patch. Reverse process again when going from B to A.

Proposed system: When migrating upwards, instead of just storing the patch version, serialize the whole patch in database for later use, though I'd probably only need the down() method. When changing branches, compare patches that have been run to patches that are available in the destination branch. Determine nearest shared patch (or oldest difference, maybe) between db table of run patches and patches in destination branch by ID or hash. Could also look for new or missing patches that are buried under a number of shared patches between the two branches.

Automatically merge down to the nearest shared patch, using the db table stored down() methods, and then merge up to the branche's latest patch.

My question is: Is this system too crazy and/or fraught with consequences to bother developing? My experience with database schema versioning is limited to PHP autopatch, which is an up()-only system requiring filenames with sequential IDs.

Update, 2 years later

This is an old post, but I wanted to mention that I've abandoned migrations in general during development as they're unnecessarily complicated and error prone.

Instead, I use build scripts to:

1. clear the database,
2. create the schema,
3. add known application data (real content), and
4. add fixture data (development content).

When changing branches, or receiving updates from other developers, you reload the database completely with one command to get to a known state.

Production servers still need database patches, but those would have to be manually created anyway.

解决方案

Well, I wasn't able to find any reason not to move forward.

The project, such as it is, is here:

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

Needs some love (accurate comments, unit testing, actual bug testing), but seems to be working well for me now.

It's a fork of http://code.google.com/p/mysql-php-migrations/ to include the ideas above, and some other little stuff.

Migrating down is done from methods saved in the database on the way up so that file changes (like those when switching between branches) do not affect downward migrations. Added two functions:

• a magic 'auto' function that handles migrating down to the oldest shared migration, and then up to the newest migration in the migrations directory.
• 'propose' function that shows what auto will actually do.

Still very open to hearing potential (or even expected) pitfalls from this approach however.

这篇关于PHP - 数据库模式：版本控制，分支，迁移的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！