在POPFile 中，我们使用自己的解决方案。我们在数据库中存储模式版本号，如果程序检测到有更新的模式，它将相应地更新数据库。这并不是我们代码中最好最有趣的部分。

老实说，如果你还没有在使用DBIx::Class，我无法看出使用DBIx::Migration::Directories的优点。您必须提供SQL和版本号和数据库句柄。您可能需要提供更多的代码来查找SQL文件并将其提供给数据库。

当然，将模式存储在版本控制中是一个很大的优势。

在工作中，我们使用了一个修改过的版本的DBIx::Migration （它有一些限制，比如不超过10次迁移）。您可以从您的数据库中导出一个核心模式，当版本号太低时，您可以使用来自迁移方案目录的迁移来升级数据库。

我也强烈推荐《数据库重构》这本书。除了其他方面，它还能为你提供优秀的技巧，帮助你以安全的方式管理迁移，这样如果你需要回滚，就不会丢失数据（例如您删除一个您认为不需要的列时）。

为了帮助自动弃用时间表，建议使用Devel::Deprecate，这样您就不需要记住何时进行弃用。您的代码将为您大声抱怨（仅在测试中，而不是在生产中）。

重要：使用此技术，您可能会定期发现正在应用太多的数据库迁移级别，以至于有时需要"提升"最小基本迁移，因为重建数据库需要太长时间。只需在所需的迁移级别上对数据库进行新的转储，并删除所有小于或等于该级别的迁移。

更新：快进几年，今天我推荐使用sqitch。它从基础开始设计，可处理将数据库放入版本控制的情况，而不会将您绑定到特定的编程语言或VCS。

一个非常有趣的项目，可能还有些年轻，不能太依赖它，这是Adam Kennedy的ORLite::Migrate，其灵感来自于Rails迁移。他在use.perl.org上写了一篇非常有趣的日志，谈到了他的计划，我希望将来能够关注它。

它似乎目前仅与SQLite一起使用，但我认为亚当计划在未来将其扩展为更多的数据库无关性。

我们使用类似Manni所描述的系统。两个大的劣势是：

• 不能回滚模式更改（通常很少见，未经充分测试且难以实现，因此必须手动执行并不是我的大问题）。

• 使用顺序版本号在开发多个分支时会很麻烦--由于您使用的是SVN，这不像使用git那样可能成为问题。 :-)

我使用的脚本是： database_update 并且还有一个小的示例数据文件。

sqitch怎么样？它自称是一款“数据库变更管理应用程序”。

这里有一个有趣的CPAN模块（Database::Migrator）。我已经使用了它，并且在处理您的项目迁移时运行良好。

每个迁移都会进入它自己的目录。迁移按顺序应用，通常你会以数字前缀命名。迁移目录可以包含带有 SQL 或 Perl 的文件。