我一直在研究将我们的数据库模式置于版本控制之下的选项。似乎 Ruby 的人有 Rails Migrations，而 .NET 的人有一些选择（例如 this、this 和 this）。 Perl 呢？
我见过这个thread on PerlMonks，虽然它提到了DBIX::Migration::Directories，但它的内容并不多。是否有人实际使用此模块或其他模块？还是您推出自己的数据库迁移解决方案？
免费细节：
【问题讨论】：
标签： database perl version-control migration
在工作中，我们使用 DBIx::Migration 的修改版本（它有一些限制，例如不超过 10 次迁移）。然后，您有一个从数据库中转储的核心架构，当版本号太低时，您可以使用迁移架构目录中的迁移来升级数据库。
我也强烈推荐Database Refactoring 这本书。除此之外，它将为您提供出色的迁移管理技术安全，这样，如果您需要回滚，您就不会丢失数据（例如，当您删除一列时，您认为不需要）。
为了帮助它建议的自动弃用计划，我写了Devel::Deprecate，这样您就不需要记住何时进行弃用。您的代码会为您大声抱怨（并且仅在测试中，而不是在生产中）。
重要提示：您会定期发现您使用这种技术应用了如此多的数据库迁移级别，以至于您有时需要“提高”您的最低要求基本迁移，因为重建数据库花费的时间太长。只需在所需的迁移级别重新转储数据库，然后删除小于或等于该级别的所有迁移。
更新：快进几年，今天我推荐sqitch。它的设计初衷是为了处理将数据库置于版本控制之下的情况，而无需将您绑定到特定的编程语言或 VCS。
【讨论】：
Adam Kennedy 的ORLite::Migrate 是一个非常有趣的项目，它可能还很年轻，但它的灵感来自 Rails 迁移。他在 use.perl.org 上 wrote up a very interesting journal 讨论了他的计划，我希望将来继续关注它。
目前看来，这个包只适用于 SQLite，但我认为 Adam 计划在未来将其构建为与数据库无关。
【讨论】：
在POPFile 中，我们使用自己的解决方案。我们将模式版本号存储在数据库中，如果程序检测到有更新的模式，它将相应地更新数据库。这并不是我们代码中最好和最有趣的部分。
说实话，如果您还没有使用 DBIx::Class，我看不到使用 DBIx::Migration::Directories 的优势。您必须提供 SQL 和版本号以及数据库句柄。您不妨提供更多代码来查找 sql 文件并将其提供给数据库。
当然，在版本控制中拥有架构是一个很大的好处。
【讨论】：
我们使用类似于 Manni 描述的系统。两大缺点是：
无法回滚架构更改（通常这种情况很少见，没有经过充分测试并且很难，因此必须手动执行 IMO 没什么大不了的）。
当您在多个分支中开发时，使用顺序版本号是一件很痛苦的事情——因为您使用的是 SVN，这不像您使用 git 那样可能是一个问题。 :-)
我使用的脚本脚本在这里：database_update，还有一个小的example data file。
【讨论】：
sqitch 怎么样？它标榜自己是一个“数据库变更管理应用程序”，
【讨论】：
有一个有趣的 CPAN 模块 (Database::Migrator)。我已经使用了它，并且可以正常工作以处理您的项目迁移。
每次迁移都进入其自己的目录。迁移按排序顺序应用，通常以数字前缀开头。迁移目录可以包含带有 SQL 或 Perl 的文件。
【讨论】：