如何使用 Perl 使我的数据库处于版本控制之下？
我一直在研究将数据库模式置于版本控制之下的选项。 Ruby 人员似乎已经有了 Rails 迁移，并且 . NET 人员有一些选择（例如 这个、这个和这个）。 那么珀尔呢？
我见过这个 PerlMonks 上的线程，虽然它提到了 < a href="http://search.cpan.org/perldoc?DBIx%3A%3AMigration%3A%3ADirectories" rel="nofollow noreferrer">DBIX::Migration::Directories。 有人真正使用这个模块或其他模块吗？ 或者您是否推出自己的数据库迁移解决方案？
无偿详细信息：
- 我们不大部分使用 DBIx::Class
- 我们使用 MySQL
- 我们使用 SVN
I've been looking at the options for getting our database schemas under version control. It seems that Ruby folks have got Rails Migrations, and .NET folks have got a few options (for instance this, this, and this). What about Perl?
I've seen this thread on PerlMonks which doesn't have much, although it mentions DBIX::Migration::Directories. Is anyone actually using this module, or some other module? Or do you roll your own DB migration solutions?
Gratuitous details:
- We don't use DBIx::Class for the most part
- We use MySQL
- We use SVN
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在工作中，我们使用 DBIx::Migration 的修改版本（它有一些限制，例如不超过 10 次迁移）。 然后，您拥有从数据库转储的核心架构，当版本号太低时，您可以使用迁移架构目录中的迁移来升级数据库。
我还强烈推荐数据库重构一书。 除此之外，它将为您提供出色的技术来安全地管理迁移，这样如果您需要回滚，您就不会丢失数据（例如，当您删除您认为应该删除的列时）不需要）。
为了帮助执行它建议的自动弃用计划，我编写了 Devel::Deprecate 这样您就不需要记住何时进行弃用。 您的代码将为您大声抱怨（并且仅在测试中，而不是在生产中）。
重要：您会定期发现使用此技术应用了如此多的数据库迁移级别，有时需要“提高”最小基础迁移，因为重建数据库花费的时间太长。 只需在所需的迁移级别上对数据库进行新的转储，并删除所有低于或等于该级别的迁移。
更新：快进几年，今天我推荐 sqitch。 它是从头开始设计的，旨在处理将数据库置于版本控制之下的情况，而无需将您绑定到特定的编程语言或 VCS。
At work, we use a modified version of DBIx::Migration (it has some limitations, such as no more than 10 migrations). Then, you have a core schema that you've dumped from your database and when the version number is too low, you upgrade your database using the migrations from the migration schema directory.
I also highly recommend the Database Refactoring book. Amongst other things, it will give you excellent techniques for managing migrations safely in such a way that if you need to roll back, you don't lose data (such as when you drop a column you think you don't need).
To help with the automatic deprecation schedules it suggests, I've written Devel::Deprecate so that you don't need to remember when to do the deprecations. Your code will complain loudly for you (and only in testing, not in production).
Important: You'll periodically find that you're applying so many database migration levels with this technique that you'll sometimes need to "bump up" your minimum base migration because it takes too long to rebuild the database. Just take a new dump of the database at the desired migration level and remove all migrations less than or equal to that level.
Update: Fast forward a few years and today I recommend sqitch. It's designed from the ground up to handle the case of putting a database under version control without tying you to a particular programming language or VCS.
Adam Kennedy 的 ORLite::Migrate< 是一个非常有趣的项目，但可能还不太成熟。 /a> 的灵感来自 Rails 迁移。 他在 use.perl.org 上写了一篇非常有趣的日记，讲述了他的计划我希望未来能继续关注它。
看来这个包目前只适用于 SQLite，但我认为 Adam 计划在未来构建这个包以使其与数据库更加无关。
One very interesting project that's still probably a little young to rely on is Adam Kennedy's ORLite::Migrate which takes it's inspiration from Rails migrations. He wrote up a very interesting journal over at use.perl.org about his plans and I hope to keep an eye on it for the future.
It does appear that this package only works with SQLite at the moment but I think Adam's planning on building this out to be more database agnostic in the future.
在 POPFile 中，我们使用自己的解决方案。 我们在数据库中存储模式版本号，如果程序检测到有更新的模式，它将相应地更新数据库。 这并不是我们代码中最好、最有趣的部分。
老实说，如果您尚未使用 DBIx::Class，我看不到使用 DBIx::Migration::Directories 的优势。 您必须提供 SQL 和版本号以及数据库句柄。 您不妨提供更多代码来查找 sql 文件并将其提供给数据库。
当然，在版本控制中拥有架构是一个很大的好处。
In POPFile we use our own solution. We store a schema version number in the db and if the program detects that there is a newer schema, it will update the db accordingly. This is not exactly the best and most fun part of our code.
To be honest, I fail to see the advantage of using DBIx::Migration::Directories if you aren't already using DBIx::Class. You have to provide the SQL and the version numbers and the database handle. You might as well provide a little more code to find the sql file and and feed it to the database.
Of course, having the schema in version control is a great bonus.
我们使用类似于曼尼所描述的系统。 两个很大的缺点是：
无法回滚架构更改（通常这种情况很少见，没有经过充分测试并且很困难，因此在我看来手动执行此操作并不是什么大问题）。
当您在多个分支中进行开发时，使用连续的版本号会很痛苦——因为您使用的是 SVN，但这不像使用 git 那样可能成为问题。 :-)
我使用的脚本脚本在这里： database_update 并且有一个小的 示例数据文件。
We use a system similar to what Manni described. The two big disadvantages are:
Can't rollback schema changes (typically this is rare, not well tested and hard anyway so having to do it manually isn't a big deal IMO).
Using a sequential version number is a pain when you develop in multiple branches -- since you are using SVN this isn't as likely to be an issue as if you were using git though. :-)
The script script I use is here: database_update and there's a small example data file.
sqitch 怎么样？ 它宣传自己是“数据库变更管理应用程序”，
How about sqitch? It advertises itself as a "database change management application",
有一个有趣的 CPAN 模块（Database::Migrator）。 我已经使用了它，并且可以很好地处理您的项目的迁移。
每个迁移都会进入其自己的目录。 迁移按排序顺序应用，通常您以数字前缀开头命名它们。 迁移目录可以包含 SQL 或 Perl 的文件。
There is an interesting CPAN module (Database::Migrator). I have used it, and works fine in order to handle the migrations of your project.
Each migration goes into its own directory. Migrations are applied in sorted order, typically you name them starting with a number prefix. The migration directory can either contain files with SQL or Perl.