我想让我的数据库处于版本控制之下。

我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能度量。

如何对数据库应用版本控制?


当前回答

如果您有一个小型数据库,并且希望对整个数据库进行版本化,那么这个批处理脚本可能会有所帮助。它将MSSQL数据库MDF文件分离、压缩并检入Subversion。

如果您主要想要版本化您的模式,并且只有少量的引用数据,您可以使用SubSonic Migrations来处理它。这样做的好处是您可以轻松地向上或向下迁移到任何特定的版本。

其他回答

我写了这个应用程序一段时间前,http://sqlschemasourcectrl.codeplex.com/,它会扫描你的MSFT SQL db的经常你想,并自动转储你的对象(表,视图,procs,函数,SQL设置)到SVN。效果非常好。我把它和unduddle一起使用(它可以让我在签到时收到提醒)

我同意ESV的答案,正是出于这个原因,我开始了一个小项目,以帮助维护一个非常简单的文件中的数据库更新,然后可以在一个很长的源代码之外进行维护。它允许对开发人员以及UAT和生产进行轻松的更新。该工具适用于SQL Server和MySQL。

项目的一些特点:

允许模式更改 允许值树填充 允许单独的测试数据插入,例如。UAT 允许回滚选项(不是自动的) 维护对SQL server和MySQL的支持 有能力导入现有的数据库到版本控制与一个简单的命令(SQL server仅…仍在开发MySQL)

请查看代码以获得更多信息。

Red Gate的SQL Compare产品不仅允许您进行对象级比较,并从中生成更改脚本,还允许您将数据库对象导出到按对象类型组织的文件夹层次结构中,其中一个[objectname]。这些目录中每个对象的SQL创建脚本。对象类型层次结构是这样的:

\功能 \安全 \安全\角色 \ \安全模式 \安全\用户 \存储过程 \表

如果在进行更改后将脚本转储到相同的根目录,则可以使用此目录更新SVN repo,并单独保存每个对象的运行历史记录。

这是围绕发展的“难题”之一。据我所知,没有完美的解决方案。

如果只需要存储数据库结构而不需要存储数据,则可以将数据库导出为SQL查询。(在企业管理器中:右键单击数据库->生成SQL脚本。我建议在选项卡上设置“每个对象创建一个文件”),然后您可以将这些文本文件提交到svn,并使用svn的diff和日志功能。

我将此与一个Batch脚本绑定在一起,该脚本采用一对参数并设置数据库。我还添加了一些额外的查询,输入默认数据,如用户类型和管理用户。(如果你想要更多关于这方面的信息,张贴一些东西,我可以把脚本放在可以访问的地方)

如果你需要保留所有的数据,我建议保留一个数据库备份,并使用Redgate (http://www.red-gate.com/)产品进行比较。它们并不便宜,但它们值每一分钱。

关于这个主题,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后都会运行此脚本。

警告:我的自动化测试运行在模式正确但空的数据库上,因此这个建议不能完全满足您的需求。