对SQL Server数据库进行版本控制
我想让我的数据库受版本控制。有人对我有什么建议或者推荐文章吗？
我总是希望至少要有一些数据(如alumb所提到的：用户类型和管理员)。我还将经常需要大量生成的测试数据来进行性能测量。
解决方案：
这是围绕发展的"难题"之一。据我所知，没有完美的## 解决方案。
如果只需要存储数据库结构而不需要存储数据，则可以将数据库导出为SQL查询。 (在企业管理器中：右键单击数据库->生成SQL脚本。我建议在选项选项卡上设置"每个对象创建一个文件")，然后可以将这些文本文件提交到svn并利用svn的diff和日志记录功能。
我将其与使用几个参数并设置数据库的批处理脚本捆绑在一起。我还添加了一些其他查询，这些查询输入默认数据，例如用户类型和admin用户。 (如果我们想要更多有关此的信息，请发布一些内容，然后我可以将脚本放在可访问的位置)
如果还需要保留所有数据，我建议保留数据库的备份，并使用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
);
每次运行与新版本相对应的升级脚本时，都会获得一个新条目。
这样可以确保轻松查看存在哪个版本的数据库架构，并且数据库升级脚本仅运行一次。同样，这些不是数据库转储。而是，每个脚本代表了从一个版本转移到下一个版本所必需的更改。它们是我们应用于生产数据库以"升级"它的脚本。
开发人员沙箱同步用于备份，清理和收缩生产数据库的脚本。每次升级到生产数据库后，请运行此命令。用于在开发人员的工作站上还原(和调整，如有必要)备份的脚本。每个开发人员在每次升级到生产数据库后都将运行此脚本。
一个警告：我的自动化测试针对的是架构正确但为空的数据库，因此该建议将无法完全满足需求。
我们没有提到有关目标环境或者约束的任何细节，因此这可能并不完全适用...但是，如果我们正在寻找一种有效跟踪不断发展的数据库模式的方法，并且不会不利于使用Ruby，ActiveRecord的迁移就在小巷。
迁移以编程方式使用Ruby DSL定义数据库转换；可以应用每个转换，也可以(通常)回滚每个转换，从而使我们可以在任何给定的时间点跳转到数据库模式的不同版本。可以像其他任何源代码一样，将定义这些转换的文件检入版本控制。
由于迁移是ActiveRecord的一部分，因此通常可以在全栈Rails应用程序中找到它们的用途。但是，我们可以以最小的努力独立于Rails使用ActiveRecord。有关在Rails之外使用AR迁移的详细信息，请参见此处。
典型的## 解决方案是根据需要转储数据库并备份那些文件。
根据开发平台，可能会有开源插件可用。滚动自己的代码来做到这一点通常是微不足道的。
注意：我们可能要备份数据库转储，而不是将其放入版本控制中。这些文件在版本控制中可能变得非常快，并导致整个源代码控制系统变慢(此刻我想起了CVS的恐怖故事)。
我们还可以查看迁移## 解决方案。这些允许我们在Ccode中指定数据库架构，并使用MSBuild上下滚动数据库版本。
我当前正在使用DbUp，并且运行良好。
我们不存储数据库模式，而是将更改存储到数据库中。我们要做的是存储模式更改，以便我们为数据库的任何版本构建更改脚本，并将其应用于客户的数据库。我编写了一个数据库实用程序应用程序，该应用程序随我们的主应用程序一起分发，该主应用程序可以读取该脚本并知道需要应用哪些更新。它还具有足够的智能，可以根据需要刷新视图和存储过程。
我们使用DBGhost来管理我们的SQL数据库。然后，将脚本放入版本控制中以构建新数据库，然后它将构建新数据库或者将任何现有数据库升级到版本控制中的架构。这样，我们不必担心创建更改脚本(尽管我们仍然可以这样做，例如，如果要更改列的数据类型并需要转换数据)。
如果数据库很小，并且想要对整个数据库进行版本控制，那么此批处理脚本可能会有所帮助。它分离，压缩并检查Subversion中的MSSQL数据库MDF文件。
如果我们主要是想对架构进行版本控制并且仅包含少量参考数据，则可以使用SubSonic Migrations进行处理。这样做的好处是我们可以轻松地向上或者向下迁移到任何特定版本。
我们刚刚开始使用Team Foundation Server。如果数据库中等大小，则Visual Studio可以通过内置的比较，数据比较，数据库重构工具，数据库测试框架甚至数据生成工具来进行一些不错的项目集成。
但是，该模型不太适合大型或者第三方数据库(用于加密对象)。因此，我们要做的是仅存储我们的自定义对象。为此，Visual Studio / Team基础服务器可以很好地工作。
TFS数据库首席拱门。博客
MS TFS网站
Red Gate的SQL Compare产品不仅允许我们进行对象级比较，并由此生成更改脚本，而且还允许我们使用一个[objectname] .sql将数据库对象导出到按对象类型组织的文件夹层次结构中。这些目录中每个对象的脚本。对象类型层次结构是这样的：
\功能
\安全
\安全\角色
\ Security \ Schemas
\ Security \ Users
\存储过程
\表
如果在进行更改后将脚本转储到相同的根目录，则可以使用它来更新SVN存储库，并分别保留每个对象的运行历史记录。
不久前，我发现了一个VB bas模块，该模块使用DMO和VSS对象将整个数据库脚本化并写入VSS。我将其转换为VB脚本并将其发布在此处。我们可以轻松地进行VSS调用，并使用DMO东西来生成所有脚本，然后从调用VBScript来检入它们的同一批处理文件中调用SVN？
戴夫J
我们可能要看一下Liquibase(http://www.liquibase.org/)。即使我们不使用该工具本身，它也可以很好地处理数据库更改管理或者重构的概念。
由于我们的应用程序必须跨多个RDBMS进行工作，因此我们使用与数据库无关的Torque格式(XML)将架构定义存储在版本控制中。我们还按如下所示以XML格式对数据库的参考数据进行版本控制(其中"关系"是参考表之一)：
<Relationship RelationshipID="1" InternalName="Manager"/> <Relationship RelationshipID="2" InternalName="Delegate"/> etc.
然后，我们使用本地工具生成从数据库的版本X到版本X + 1所需的架构升级和参考数据升级脚本。
用更改脚本将数据库脚本保存到版本控制中是一种好方法，这样我们就可以升级拥有的任何一个数据库。另外，我们可能希望保存不同版本的架构，以便无需创建所有更改脚本即可创建完整的数据库。脚本的处理应该是自动化的，这样我们就不必进行手动工作。
我认为为每个开发人员使用单独的数据库而不使用共享数据库很重要。这样，开发人员可以独立于其他开发人员创建测试案例和开发阶段。
自动化工具应该具有处理数据库元数据的方法，该方法可以告诉哪些数据库处于什么开发状态以及哪些表包含版本可控制的数据等等。
为了使转储到源代码控制系统的速度更快一点，我们可以使用sysobjects中的版本信息来查看自上次以来哪些对象已更改。
设置：在每个要增量检查的数据库中创建一个表，以保存上次检查该数据库以来的版本信息(第一次运行时为空)。如果要重新扫描整个数据结构，请清除此表。
IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
正常运行模式：我们可以从此sql中获取结果，并为我们感兴趣的脚本生成sql脚本，然后将其放入我们选择的源代码控件中。
IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
name varchar(128),
id int, base_schema_ver int,
schema_ver int,
type char(2)
)
SET NOCOUNT ON
-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions
DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects
-- This next bit lists all differences to scripts.
SET NOCOUNT OFF
--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION
--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/,
'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE (
o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver <> t.schema_ver
)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT oi.name
FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
WHERE oi.name <> ti.name /*COLLATE*/
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
AND t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
WHERE o.id = t.id)
AND t.name NOT IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
WHERE NOT EXISTS (SELECT * FROM #tmp ti
WHERE oi.id = ti.id)
AND oi.type IN ('TR', 'P' ,'U' ,'V'))
UNION
--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
WHERE o.id = t.id)
AND o.type IN ('TR', 'P' ,'U' ,'V')
AND o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
WHERE NOT EXISTS (SELECT * FROM sysobjects oi
WHERE oi.id = ti.id))
ORDER BY Priority ASC
注意：如果在任何数据库中使用非标准排序规则，则需要用数据库排序规则替换/ * COLLATE * /。即COLLATE Latin1_General_CI_AI
迁移到x64平台后，我们需要对SQL数据库进行版本控制，而旧版本因迁移而中断。我们编写了一个C应用程序，该应用程序使用SQLDMO将所有SQL对象映射到一个文件夹：
Root
ServerName
DatabaseName
Schema Objects
Database Triggers*
.ddltrigger.sql
Functions
..function.sql
Security
Roles
Application Roles
.approle.sql
Database Roles
.role.sql
Schemas*
.schema.sql
Users
.user.sql
Storage
Full Text Catalogs*
.fulltext.sql
Stored Procedures
..proc.sql
Synonyms*
.synonym.sql
Tables
..table.sql
Constraints
...chkconst.sql
...defconst.sql
Indexes
...index.sql
Keys
...fkey.sql
...pkey.sql
...ukey.sql
Triggers
...trigger.sql
Types
User-defined Data Types
..uddt.sql
XML Schema Collections*
..xmlschema.sql
Views
..view.sql
Indexes
...index.sql
Triggers
...trigger.sql
然后，应用程序会将新编写的版本与SVN中存储的版本进行比较，如果存在差异，它将更新SVN。
我们确定每晚运行一次该进程就足够了，因为我们没有对SQL进行太多更改。它使我们能够跟踪对我们关心的所有对象的更改，并且还允许我们在出现严重问题时重建完整的架构。
为所有推荐RedGate工具的人+1，以及额外的建议和警告。
SqlCompare还具有记录良好的API：因此，例如，我们可以编写一个控制台应用程序，该应用程序在签入时将源代码控制脚本文件夹与CI集成测试数据库同步，以便当有人从其脚本文件夹中检查对模式的更改时它会与匹配的应用程序代码更改一起自动部署。这有助于消除与忘记将本地数据库中的更改传播到共享开发数据库的开发人员之间的差距(我认为，大约一半的人)。
需要注意的是，无论采用脚本## 解决方案还是其他方式，RedGate工具都足够平滑，以至于很容易忘记抽象底层的SQL现实。如果重命名表中的所有列，则SqlCompare无法将旧列映射到新列，并且将删除表中的所有数据。它将生成警告，但我已经看到人们点击了该警告。我认为，这里有一个值得说明的一般要点：到目前为止，我们只能自动化数据库版本控制和升级，而抽象是非常容易泄漏的。
我还在数据库中使用通过数据库扩展属性系列过程存储的版本。我的应用程序具有每个版本步骤的脚本(即，从1.1到1.2)。部署后，它将查看当前版本，然后逐个运行脚本，直到到达最后一个应用程序版本。没有脚本具有直接的"最终"版本，即使在干净的数据库上进行部署也需要通过一系列升级步骤来进行部署。
现在，我要补充的是，两天前我在MS校园中看到了有关新的和即将推出的VS DB版本的演示。演讲专门针对这个主题，我被淹没了。我们绝对应该检查一下，新功能集中在将模式定义保留在T-SQL脚本(CREATE)中，运行时增量引擎将部署模式与定义的模式进行比较，并进行增量ALTER和与源代码集成的集成，直至并包括MSBUILD持续集成以实现自动构建删除。该放置将包含一个新的文件类型.dbschema文件，可以将其带到部署站点，并且命令行工具可以执行实际的"增量"并运行部署。
我有一个关于此主题的博客条目，其中包含指向VSDE下载的链接，我们应该查看它们：http://rusanu.com/2009/05/15/version-control-and-your-database/
这很简单。
基础项目准备就绪后，我们必须创建完整的数据库脚本。该脚本已提交给SVN。这是第一个版本。
之后，所有开发人员都会创建更改脚本(ALTER ...，新表，存储过程等)。
当需要当前版本时，应执行所有新的更改脚本。
将应用程序发布到生产环境后，我们将返回到1(但随后它将是连续的版本)。
Nant将执行那些更改脚本。 :)
记住有纪律的话一切都很好。每次提交数据库更改时，代码中的相应功能也会被提交。
每个数据库都应受源代码控制。缺少的是一种自动将所有数据库对象和"配置数据"写入文件的工具，然后可以将其添加到任何源代码管理系统中。如果我们使用的是SQL Server，那么我的## 解决方案在这里：http://dbsourcetools.codeplex.com/。玩得开心。
内森
以我的经验，## 解决方案是双重的：
我们需要处理开发人员在开发过程中对开发数据库所做的更改。
我们需要在客户站点中处理数据库升级。
为了处理＃1，我们将需要一个强大的数据库差异/合并工具。最好的工具应该能够执行尽可能多的自动合并，同时允许我们手动解决未处理的冲突。
完美的工具应该通过使用三向合并算法来处理合并操作，该算法考虑了THEIRS数据库和MINE数据库相对于BASE数据库所做的更改。
我写了一个商业工具，它为SQLite数据库提供了手动合并支持，而我目前正在添加对SQLite的三向合并算法的支持。在http://www.sqlitecompare.com上进行检查
为了处理＃2，我们将需要一个升级框架。
基本思想是开发一个自动升级框架，该框架知道如何从现有的SQL模式升级到较新的SQL模式，并可以为每个现有的数据库安装构建升级路径。
在http://www.codeproject.com/KB/database/sqlite_upgrade.aspx中查看有关该主题的文章，以大致了解我在说什么。
祝你好运
利隆·列维(Liron Levi)
请访问DBGhost http://www.innovartis.co.uk/。我已经以自动化方式使用了2年，效果很好。它使我们的数据库构建可以像Java或者C一样进行，数据库除外。你知道我的意思。
在Red Gate，我们提供了一个工具SQL Source Control，该工具使用SQL Compare技术将数据库与TFS或者SVN存储库链接。该工具已集成到SSMS中，使我们可以照常工作，但现在可以提交对象。
对于基于迁移的方法(更适合于自动部署)，我们提供ReadyRoll，它可以作为Visual Studio项目创建和管理一组增量脚本。
在SQL Source Control中，可以指定静态数据表。这些作为INSERT语句存储在源代码管理中。
如果我们在谈论测试数据，我们建议我们使用工具或者通过定义的部署后脚本生成测试数据，或者仅将生产备份还原到开发环境。
我前一阵子写了这个程序http://sqlschemasourcectrl.codeplex.com/，它将根据需要扫描MSFT SQL数据库，并自动将对象(表，视图，proc，函数，sql设置)转储到SVN中。奇迹般有效。我将它与Unfuddle结合使用(这使我可以获得签到的警报)
