我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
当前回答
根据我的经验,解决方法有两个:
您需要处理开发数据库的更改,这些更改是由多个开发人员在开发期间完成的。 需要处理客户站点的数据库升级。
为了处理#1,你需要一个强大的数据库差异/合并工具。最好的工具应该能够尽可能地执行自动合并,同时允许您手动解决未处理的冲突。
完美的工具应该通过使用3-way合并算法来处理合并操作,该算法考虑到相对于BASE数据库在their数据库和MINE数据库中所做的更改。
我写了一个商业工具,为SQLite数据库提供手动合并支持,我目前正在为SQLite添加3路合并算法的支持。请登录http://www.sqlitecompare.com查看
为了处理第2点,你需要一个升级框架。
基本思想是开发一个自动升级框架,该框架知道如何从现有的SQL模式升级到更新的SQL模式,并且可以为每个现有的DB安装构建一个升级路径。
在http://www.codeproject.com/KB/database/sqlite_upgrade.aspx上查看我关于这个主题的文章,了解我所说的内容。
祝你好运
利龙·列维
其他回答
Red Gate的SQL Compare产品不仅允许您进行对象级比较,并从中生成更改脚本,还允许您将数据库对象导出到按对象类型组织的文件夹层次结构中,其中一个[objectname]。这些目录中每个对象的SQL创建脚本。对象类型层次结构是这样的:
\功能 \安全 \安全\角色 \ \安全模式 \安全\用户 \存储过程 \表
如果在进行更改后将脚本转储到相同的根目录,则可以使用此目录更新SVN repo,并单独保存每个对象的运行历史记录。
典型的解决方案是根据需要转储数据库并备份这些文件。
根据您的开发平台,可能会有可用的开源插件。编写自己的代码来完成这个任务通常是相当简单的。
注意:您可能希望备份数据库转储,而不是将其放入版本控制中。在版本控制中,文件可能会迅速变大,并导致整个源代码控制系统变慢(我正在回忆CVS的恐怖故事)。
每个数据库都应该在源代码控制下。目前缺少的是一种工具,可以自动将所有数据库对象(以及“配置数据”)脚本化为文件,然后将其添加到任何源代码控制系统。如果你正在使用SQL Server,那么我的解决方案在这里:http://dbsourcetools.codeplex.com/。玩得开心。 -内森。
你没有提到任何关于目标环境或约束的细节,所以这可能并不完全适用……但如果您正在寻找一种有效跟踪不断变化的DB模式的方法,并且不反对使用Ruby, ActiveRecord的迁移正适合您。
迁移使用Ruby DSL以编程方式定义数据库转换;每个转换都可以应用或(通常)回滚,允许您在任何给定的时间点跳转到您的DB模式的不同版本。定义这些转换的文件可以像任何其他源代码一样检入版本控制。
因为迁移是ActiveRecord的一部分,它们通常在全栈Rails应用程序中使用;然而,你可以用最少的努力独立于Rails使用ActiveRecord。请参阅这里,了解在Rails之外使用AR迁移的更详细处理。
每个推荐RedGate工具的人都要加1分,还有额外的建议和警告。
SqlCompare also has a decently documented API: so you can, for instance, write a console app which syncs your source controlled scripts folder with a CI integration testing database on checkin, so that when someone checks in a change to the schema from their scripts folder it's automatically deployed along with the matching application code change. This helps close the gap with developers who are forgetful about propagating changes in their local db up to a shared development DB (about half of us, I think :) ).
A caveat is that with a scripted solution or otherwise, the RedGate tools are sufficiently smooth that it's easy to forget about SQL realities underlying the abstraction. If you rename all the columns in a table, SqlCompare has no way to map the old columns to the new columns and will drop all the data in the table. It will generate warnings but I've seen people click past that. There's a general point here worth making, I think, that you can only automate DB versioning and upgrade so far - the abstractions are very leaky.