我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
我想让我的数据库处于版本控制之下。
我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。
如何对数据库应用版本控制?
当前回答
因为我们的应用程序必须跨多个rdbms工作,所以我们使用与数据库无关的Torque格式(XML)将模式定义存储在版本控制中。我们还以以下XML格式对数据库的引用数据进行版本控制(其中“关系”是其中一个引用表):
<Relationship RelationshipID="1" InternalName="Manager"/>
<Relationship RelationshipID="2" InternalName="Delegate"/>
etc.
然后,我们使用自己开发的工具来生成从数据库版本X到版本X + 1所需的模式升级和引用数据升级脚本。
其他回答
我写了这个应用程序一段时间前,http://sqlschemasourcectrl.codeplex.com/,它会扫描你的MSFT SQL db的经常你想,并自动转储你的对象(表,视图,procs,函数,SQL设置)到SVN。效果非常好。我把它和unduddle一起使用(它可以让我在签到时收到提醒)
关于这个主题,Martin Fowler写了一篇我最喜欢的文章http://martinfowler.com/articles/evodb.html。我选择不像alumb和其他人建议的那样将模式转储放在版本控制下,因为我想要一种简单的方法来升级我的生产数据库。
对于一个web应用程序,我将有一个生产数据库实例,我使用两种技术:
数据库升级脚本
一个序列数据库升级脚本,其中包含将模式从版本N移动到版本N+1所需的DDL。(这些会进入你的版本控制系统。)一个_version_history_表,类似于
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
每次运行与新版本对应的升级脚本时获取一个新条目。
这可以确保很容易查看数据库模式的版本,并且数据库升级脚本只运行一次。同样,这些不是数据库转储。相反,每个脚本表示从一个版本迁移到下一个版本所需的更改。它们是应用于生产数据库以“升级”它的脚本。
开发人员沙箱同步
备份、清理和收缩生产数据库的脚本。在每次升级到生产DB后运行此命令。 在开发人员的工作站上恢复(并在必要时调整)备份的脚本。每个开发人员在每次升级到生产DB后都会运行此脚本。
警告:我的自动化测试运行在模式正确但空的数据库上,因此这个建议不能完全满足您的需求。
您还可以考虑迁移解决方案。它们允许您在c#代码中指定数据库模式,并使用MSBuild上下滚动数据库版本。
我目前正在使用DbUp,它工作得很好。
这很简单。
当基础项目准备就绪时,您必须创建完整的数据库脚本。此脚本提交给SVN。这是第一个版本。 之后,所有开发人员创建更改脚本(ALTER…,新表,sprocs等)。 当您需要当前版本时,您应该执行所有新的更改脚本。 当应用程序发布到生产环境时,你会回到1(当然,那将是连续版本)。
Nant将帮助您执行这些更改脚本。:)
记住。只要有纪律,一切都能顺利进行。每次提交数据库更改时,代码中相应的函数也会被提交。
我还使用了数据库中通过数据库扩展属性家族存储的一个版本的过程。我的应用程序有脚本的每个版本的步骤(即。从1.1移动到1.2)。部署时,它会查看当前版本,然后逐个运行脚本,直到到达最后一个应用程序版本。没有脚本有直接的“最终”版本,即使部署在干净的DB上也会通过一系列升级步骤进行部署。
Now what I like to add is that I've seen two days ago a presentation on the MS campus about the new and upcoming VS DB edition. The presentation was focused specifically on this topic and I was blown out of the water. You should definitely check it out, the new facilities are focused on keeping schema definition in T-SQL scripts (CREATEs), a runtime delta engine to compare deployment schema with defined schema and doing the delta ALTERs and integration with source code integration, up to and including MSBUILD continuous integration for automated build drops. The drop will contain a new file type, the .dbschema files, that can be taken to the deployment site and a command line tool can do the actual 'deltas' and run the deployment. I have a blog entry on this topic with links to the VSDE downloads, you should check them out: http://rusanu.com/2009/05/15/version-control-and-your-database/