跟踪数据库架构更改的机制 [英] Mechanisms for tracking DB schema changes

查看:26
本文介绍了跟踪数据库架构更改的机制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

跟踪和/或自动化数据库架构更改的最佳方法是什么?我们的团队使用 Subversion 进行版本控制,我们已经能够以这种方式自动化我们的一些任务(将构建推送到临时服务器,将测试代码部署到生产服务器),但我们仍然手动进行数据库更新.我想找到或创建一个解决方案,使我们能够在具有不同环境的服务器之间高效工作,同时继续使用 Subversion 作为后端,通过该后端将代码和数据库更新推送到各种服务器.

What are the best methods for tracking and/or automating DB schema changes? Our team uses Subversion for version control and we've been able to automate some of our tasks this way (pushing builds up to a staging server, deploying tested code to a production server) but we're still doing database updates manually. I would like to find or create a solution that allows us to work efficiently across servers with different environments while continuing to use Subversion as a backend through which code and DB updates are pushed around to various servers.

许多流行的软件包都包含自动更新脚本,可检测数据库版本并应用必要的更改.即使在更大范围内(跨多个项目,有时也跨多个环境和语言),这是最好的方法吗?如果是这样,是否有任何现有代码可以简化流程,还是最好仅推出我们自己的解决方案?有没有人之前实现过类似的东西并将其集成到 Subversion post-commit 钩子中,或者这是一个坏主意?

Many popular software packages include auto-update scripts which detect DB version and apply the necessary changes. Is this the best way to do this even on a larger scale (across multiple projects and sometimes multiple environments and languages)? If so, is there any existing code out there that simplifies the process or is it best just to roll our own solution? Has anyone implemented something similar before and integrated it into Subversion post-commit hooks, or is this a bad idea?

虽然支持多个平台的解决方案更可取,但我们肯定需要支持 Linux/Apache/MySQL/PHP 堆栈,因为我们的大部分工作都在该平台上进行.

While a solution that supports multiple platforms would be preferable, we definitely need to support the Linux/Apache/MySQL/PHP stack as the majority of our work is on that platform.

推荐答案

在 Rails 世界中,有迁移的概念,即使用 Ruby 更改数据库的脚本,而不是特定于数据库的 SQL.您的 Ruby 迁移代码最终会被转换为特定于您当前数据库的 DDL;这使得切换数据库平台非常容易.

In the Rails world, there's the concept of migrations, scripts in which changes to the database are made in Ruby rather than a database-specific flavour of SQL. Your Ruby migration code ends up being converted into the DDL specific to your current database; this makes switching database platforms very easy.

对于您对数据库所做的每一次更改,您都会编写一个新的迁移.迁移通常有两种方法:应用更改的向上"方法和撤消更改的向下"方法.单个命令使数据库更新,也可用于将数据库更新到特定版本的模式.在 Rails 中,迁移保存在项目目录中自己的目录中,并像任何其他项目代码一样被签入版本控制.

For every change you make to the database, you write a new migration. Migrations typically have two methods: an "up" method in which the changes are applied and a "down" method in which the changes are undone. A single command brings the database up to date, and can also be used to bring the database to a specific version of the schema. In Rails, migrations are kept in their own directory in the project directory and get checked into version control just like any other project code.

这个Oracle Rails 迁移指南很好地涵盖了迁移.

使用其他语言的开发人员已经研究了迁移并实现了他们自己的特定于语言的版本.我知道 Ruckusing,一个 PHP 迁移系统这是在 Rails 迁移之后建模的;这可能就是您要找的东西.

Developers using other languages have looked at migrations and have implemented their own language-specific versions. I know of Ruckusing, a PHP migrations system that is modelled after Rails' migrations; it might be what you're looking for.

这篇关于跟踪数据库架构更改的机制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆