最佳数据库更改控制方法

在没有外部工具的帮助下,最简单的方法就是创建一个“模式补丁”,如果愿意的话。模式补丁只是一个简单的T-SQL脚本。模式修补程序在脚本中得到一个版本号,这个版本号存储在数据库中的一个表中以接收更改。

对数据库的任何新更改都涉及到创建一个新的模式修补程序,然后您可以按顺序运行该修补程序,然后检测数据库当前所处的版本,并在其间运行所有模式修补程序。之后,模式版本表将更新为执行补丁以存储下次运行的日期/时间。

像这样详细的一本好书叫做 Refactoring Databases .

如果您希望使用外部工具,可以查看 Ruby's Migrations 项目或C中的类似工具 Migrator.NET . 这些工具通过创建带有“向前”和“向后”迁移的C类/Ruby类来工作。这些工具功能更丰富,因为它们知道如何在模式补丁中前进和后退。不过,正如您所说,您对外部工具不感兴趣,但我想无论如何,我会为其他读者补充这一点。

我很喜欢这个系列: http://odetocode.com/Blogs/scott/archive/2008/02/03/11746.aspx

在我的示例中,每次更改数据库时都会生成一个脚本,我将该脚本命名为00001.sql、n.sql,并且我有一个表,其中包含我执行的最后一个脚本的代码。你也可以看到 Database Documentation

只要将列/表添加到数据库中,就很容易在SQL文件中预先编写这些更改的脚本。你只是执行它们。也许你有命令要执行它们。

一个好的解决方案是为每个表生成一个文件,这样,所有属于该表的更改都将对曾经在该表上工作过的人可见(就像在类上工作一样)。对存储过程或视图同样有效。

更困难的任务(因此,工具可能是好的)是退后一步。只要您刚刚添加了表/列,这可能不会是一个大问题。但是,如果在更新中删除了列,现在必须撤消更新,那么数据就不再存在了。您需要从备份中获取这些数据。但请记住,如果您有更多的表,这可能是一个大任务,在正常情况下,您应该非常快地撤消更新!

如果您可以恢复备份,那么现在就可以了。但是,如果您在星期一更新,您的客户机将工作到星期三,然后他们看到一些数据丢失(您刚从表中删除),那么您就不能只恢复旧的数据库。

我在头脑中有一种基于模型的方法(抱歉,目前还没有实现),其中模式更改是“建模的”(例如每XML),在更新过程中,处理器(例如C程序)创建所有必要的“SQL”,并将数据移动到“DropDatabase”。数据可以驻留在那里,如果出于某种原因我需要恢复一些丢失的数据,我可以用处理器来完成。我认为,经过一段时间(几年)后,这种方法并没有那么糟糕,因为否则开发人员不会碰“旧”表,因为他们不再知道表或列是否真的是必需的。用这种方法,如果你掉了什么东西,你就不会冒太大的风险!

我所做的是:

• 重新创建模式所需的所有DDL命令(以及存储过程和索引等)都在脚本中。
• 为了确保脚本是正常的,它会不时进行测试(创建一个数据库,运行脚本并还原备份,然后检查数据库是否正常工作)。
• 对于变更控制,脚本保存在版本控制系统中(我通常使用Subversion)。

诀窍是,如果数据库不能通过添加的列重新创建,那么 二 要进行的更改,更改表+脚本中的修改。还有一点工作,但从长远来看,它是成功的。