我想让我的数据库处于版本控制之下。
我总是希望那里至少有一些数据(正如alumb提到的:用户类型和管理员)。我还经常需要大量生成的测试数据来进行性能测量。
如何将版本控制应用于我的数据库?
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
);
每次运行与新版本相对应的升级脚本时都会获取一个新条目。
这样可以确保很容易查看存在的数据库模式版本,并且数据库升级脚本只运行一次。同样,这些不是数据库转储。相反,每个脚本代表从一个版本移动到下一个版本所需的更改。它们是您应用于生产数据库以“升级”它的脚本。
一个警告:我的自动化测试是针对一个模式正确但空的数据库运行的,所以这个建议不能完全满足你的需要。
Red Gate 的 SQL Compare 产品不仅允许您进行对象级别的比较,并从中生成更改脚本,而且还允许您将数据库对象导出到按对象类型组织的文件夹层次结构中,只需创建一个 [objectname].sql这些目录中的每个对象的脚本。对象类型层次结构如下:
\Functions
\Security
\Security\Roles
\Security\Schemas
\Security\Users
\Stored Procedures
\Tables
如果您在进行更改后将脚本转储到同一根目录,则可以使用它来更新您的 SVN 存储库,并单独保留每个对象的运行历史记录。
这是围绕发展的“难题”之一。据我所知,没有完美的解决方案。
如果您只需要存储数据库结构而不是数据,您可以将数据库导出为 SQL 查询。(在企业管理器中:右键单击数据库 -> 生成 SQL 脚本。我建议在选项选项卡上设置“为每个对象创建一个文件”)然后您可以将这些文本文件提交到 svn 并使用 svn 的 diff 和日志记录功能。
我将它与一个批处理脚本绑定在一起,该脚本接受几个参数并设置数据库。我还添加了一些额外的查询来输入用户类型和管理员用户等默认数据。(如果您想了解更多信息,请发布一些内容,我可以将脚本放在可访问的地方)
如果您还需要保留所有数据,我建议您备份数据库并使用 Redgate ( http://www.red-gate.com/ ) 产品进行比较。它们并不便宜,但值得每一分钱。
首先,您必须选择适合您的版本控制系统:
集中式版本控制系统 - 用户在处理文件之前/之后签出/签入的标准系统,文件保存在单个中央服务器中
分布式版本控制系统 - 正在克隆存储库的系统,每个克隆实际上是存储库的完整备份,因此如果任何服务器崩溃,则可以使用任何克隆的存储库来恢复它 选择适合您需要的正确系统后,您需要设置作为每个版本控制系统核心的存储库所有这些都在以下文章中进行了解释:http: //solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -源代码控制基础/
设置存储库后,如果是中央版本控制系统的工作文件夹,您可以阅读这篇文章。它展示了如何在开发环境中使用以下方法设置源代码控制:
通过 MSSCCI 提供程序的 SQL Server Management Studio,
Visual Studio 和 SQL Server 数据工具
在 Red Gate,我们提供了一种工具SQL Source Control,它使用 SQL Compare 技术将您的数据库与 TFS 或 SVN 存储库链接。此工具集成到 SSMS 中,让您可以像往常一样工作,但现在它允许您提交对象。
对于基于迁移的方法(更适合自动化部署),我们提供SQL 变更自动化(以前称为 ReadyRoll),它可以将一组增量脚本作为 Visual Studio 项目创建和管理。
在 SQL Source Control 中,可以指定静态数据表。这些作为 INSERT 语句存储在源代码管理中。
如果您谈论的是测试数据,我们建议您使用工具或通过您定义的部署后脚本生成测试数据,或者您只需将生产备份恢复到开发环境。
您可能想查看 Liquibase ( http://www.liquibase.org/ )。即使您不使用该工具本身,它也可以很好地处理数据库更改管理或重构的概念。
+1 为推荐 RedGate 工具的每个人提供额外的建议和警告。
SqlCompare 还有一个文档化的 API:例如,您可以编写一个控制台应用程序,在签入时将源代码控制的脚本文件夹与 CI 集成测试数据库同步,这样当有人从他们的脚本文件夹签入对架构的更改时它会与匹配的应用程序代码更改一起自动部署。这有助于缩小与忘记将本地数据库中的更改传播到共享开发数据库的开发人员之间的差距(我认为大约有一半的开发人员 :))。
需要注意的是,使用脚本解决方案或其他方式,RedGate 工具足够流畅,很容易忘记抽象背后的 SQL 现实。如果重命名表中的所有列,SqlCompare 无法将旧列映射到新列,并将删除表中的所有数据。它会产生警告,但我看到人们点击过去。我认为,这里有一个值得一提的普遍观点,即到目前为止,您只能自动化数据库版本控制和升级——抽象非常容易泄漏。
我们使用DBGhost来管理我们的 SQL 数据库。然后你把你的脚本在你的版本控制中构建一个新的数据库,它要么构建一个新的数据库,要么将任何现有的数据库升级到版本控制中的模式。这样您就不必担心创建更改脚本(尽管您仍然可以这样做,例如,如果您想更改列的数据类型并需要转换数据)。
在 VS 2010 中,使用数据库项目。
打造完美的数据库版本控制解决方案,让数据库同步变得轻而易举。
您还可以查看迁移解决方案。这些允许您在 C# 代码中指定您的数据库架构,并使用 MSBuild 向上和向下滚动您的数据库版本。
我目前正在使用DbUp,并且运行良好。
使用更改脚本将数据库脚本保存到版本控制中是一种很好的方法,这样您就可以升级您拥有的任何数据库。此外,您可能希望保存不同版本的模式,以便无需应用所有更改脚本即可创建完整数据库。处理脚本应该是自动化的,这样您就不必进行手动工作。
我认为为每个开发人员拥有一个单独的数据库而不使用共享数据库很重要。这样,开发人员可以独立于其他开发人员创建测试用例和开发阶段。
自动化工具应该有处理数据库元数据的方法,它告诉哪些数据库处于什么开发状态,哪些表包含版本可控数据等等。
您没有提及有关您的目标环境或约束的任何细节,因此这可能并不完全适用......但是如果您正在寻找一种有效跟踪不断发展的数据库模式并且不反对使用的想法的方法Ruby,ActiveRecord 的迁移就在你的小巷里。
迁移使用 Ruby DSL 以编程方式定义数据库转换;每个转换都可以应用或(通常)回滚,允许您在任何给定时间点跳转到不同版本的数据库模式。定义这些转换的文件可以像任何其他源代码一样签入版本控制。
因为迁移是ActiveRecord的一部分,所以它们通常在全栈 Rails 应用程序中使用;但是,您可以毫不费力地使用独立于 Rails 的 ActiveRecord。有关在Rails 之外使用 AR 迁移的更详细的处理方法,请参见此处。
每个数据库都应该在源代码控制之下。缺少的是一种工具,可以自动将所有数据库对象和“配置数据”写入文件,然后可以将其添加到任何源代码控制系统中。如果您使用的是 SQL Server,那么我的解决方案在这里:http ://dbsourcetools.codeplex.com/ 。玩得开心。- 内森。
这很简单。
当基础项目准备好后,您必须创建完整的数据库脚本。此脚本已提交给 SVN。这是第一个版本。
之后,所有开发人员都会创建更改脚本(ALTER...、新表、存储过程等)。
当您需要当前版本时,您应该执行所有新的更改脚本。
当应用程序发布到生产环境时,您会返回到 1(但它当然会是后续版本)。
Nant 将帮助您执行这些更改脚本。:)
记住。当有纪律时,一切都很好。每次提交数据库更改时,也会提交代码中的相应函数。
如果您有一个小型数据库并且想要对整个事物进行版本控制,那么这个批处理脚本可能会有所帮助。它分离、压缩 MSSQL 数据库 MDF 文件并将其签入 Subversion。
如果您主要想对架构进行版本化并且只有少量参考数据,则可以使用SubSonic Migrations来处理它。这样做的好处是您可以轻松地向上或向下迁移到任何特定版本。
因为我们的应用程序必须跨多个 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 */
为您的数据库排序规则。IECOLLATE Latin1_General_CI_AI
我不久前写了这个应用程序,http: //sqlschemasourcectrl.codeplex.com/ 它将根据需要扫描您的 MSFT SQL 数据库,并自动将您的对象(表、视图、过程、函数、sql 设置)转储到 SVN。奇迹般有效。我将它与 Unfuddle 一起使用(它允许我在签到时收到警报)
典型的解决方案是根据需要转储数据库并备份这些文件。
根据您的开发平台,可能有可用的开源插件。滚动你自己的代码来完成它通常是相当微不足道的。
注意:您可能希望备份数据库转储而不是将其放入版本控制中。这些文件在版本控制中会变得非常快,并导致整个源代码控制系统变慢(我现在回忆起一个 CVS 恐怖故事)。
迁移到 x64 平台后,我们需要对 SQL 数据库进行版本控制,而我们的旧版本因迁移而中断。我们编写了一个 C# 应用程序,它使用 SQLDMO 将所有 SQL 对象映射到一个文件夹:
根 服务器名称 数据库名称 模式对象 数据库触发器* .ddltrigger.sql 职能 ..function.sql 安全 角色 应用程序角色 .approle.sql 数据库角色 .role.sql 架构* .schema.sql 用户 .user.sql 贮存 全文目录* .全文.sql 存储过程 ..proc.sql 同义词* .synonym.sql 表 ..table.sql 约束 ...chkconst.sql ...defconst.sql 索引 ...索引.sql 钥匙 ... fkey.sql ...pkey.sql ...ukey.sql 触发器 ...触发器.sql 类型 用户定义的数据类型 ..uddt.sql XML 模式集合* ..xmlschema.sql 意见 ..view.sql 索引 ...索引.sql 触发器 ...触发器.sql
然后,应用程序会将新编写的版本与存储在 SVN 中的版本进行比较,如果有差异,它将更新 SVN。我们确定每晚运行一次该过程就足够了,因为我们没有对 SQL 进行太多更改。它允许我们跟踪对我们关心的所有对象的更改,并且它允许我们在出现严重问题时重建我们的完整模式。
我同意 ESV 的回答,出于这个确切原因,我不久前开始了一个小项目,以帮助在一个非常简单的文件中维护数据库更新,然后可以维护一个长边源代码。它允许对开发人员以及 UAT 和生产进行轻松更新。该工具适用于 SQL Server 和 MySQL。
一些项目特点:
请查看代码以获取更多信息。
这是一个非常古老的问题,然而,即使是现在,也有很多人试图解决这个问题。他们所要做的就是研究 Visual Studio 数据库项目。没有这个,任何数据库开发看起来都非常软弱。从代码组织到部署再到版本控制,它简化了一切。
我们刚刚开始使用 Team Foundation Server。如果你的数据库是中型的,那么 Visual Studio 有一些很好的项目集成,内置比较、数据比较、数据库重构工具、数据库测试框架,甚至数据生成工具。
但是,该模型不太适合非常大的数据库或第三方数据库(加密对象)。所以,我们所做的是只存储我们自定义的对象。Visual Studio / Team Foundation Server 非常适合这一点。
不久前,我发现了一个 VB bas 模块,它使用 DMO 和 VSS 对象将整个数据库脚本化并放入 VSS。我把它变成了一个 VB 脚本并在这里发布。您可以轻松地取出 VSS 调用并使用 DMO 的东西来生成所有脚本,然后从调用 VBScript 的同一个批处理文件中调用 SVN 来签入它们。
我还在通过数据库扩展属性系列过程存储的数据库中使用一个版本。我的应用程序有每个版本步骤的脚本(即从 1.1 移动到 1.2)。部署后,它会查看当前版本,然后逐个运行脚本,直到到达最后一个应用程序版本。没有具有直接“最终”版本的脚本,即使部署在干净的数据库上,也会通过一系列升级步骤进行部署。
现在我想补充的是,两天前我在 MS 校园看到了关于新的和即将推出的 VS DB 版本的演示。演示文稿专门针对这个主题,我被炸飞了。您绝对应该检查一下,新工具专注于在 T-SQL 脚本 (CREATE) 中保留模式定义,这是一个运行时增量引擎,用于将部署模式与定义的模式进行比较,并执行增量 ALTER 和与源代码集成的集成,最多并包括用于自动构建删除的 MSBUILD 持续集成。drop 将包含一种新的文件类型,即 .dbschema 文件,可以将其带到部署站点,并且命令行工具可以执行实际的“增量”并运行部署。我有一篇关于此主题的博客文章,其中包含 VSDE 下载的链接,您应该查看它们:http://rusanu.com/2009/05/15/version-control-and-your-database/
根据我的经验,解决方案是双重的:
您需要处理多个开发人员在开发过程中对开发数据库所做的更改。
您需要处理客户站点中的数据库升级。
为了处理#1,您需要一个强大的数据库差异/合并工具。最好的工具应该能够尽可能地执行自动合并,同时允许您手动解决未处理的冲突。
完美的工具应该通过使用 3 路合并算法来处理合并操作,该算法考虑到在 THEIRS 数据库和 MINE 数据库中所做的更改,相对于 BASE 数据库。
我编写了一个为 SQLite 数据库提供手动合并支持的商业工具,我目前正在为 SQLite 添加对 3 路合并算法的支持。在http://www.sqlitecompare.com上查看
为了处理#2,您将需要一个升级框架。
基本思想是开发一个自动升级框架,该框架知道如何从现有的 SQL 模式升级到更新的 SQL 模式,并且可以为每个现有的数据库安装构建升级路径。
查看我在http://www.codeproject.com/KB/database/sqlite_upgrade.aspx中关于该主题的文章,以大致了解我在说什么。
祝你好运
利龙·列维
查看 DBGhost http://www.innovartis.co.uk/。我已经以自动化方式使用了 2 年,效果很好。它允许我们的数据库构建就像 Java 或 C 构建一样发生,除了数据库。你知道我的意思。
我建议使用比较工具为您的数据库即兴创作版本控制系统。两个不错的选择是xSQL Schema Compare和xSQL Data Compare。
现在,如果您的目标是仅将数据库的模式置于版本控制之下,您可以简单地使用 xSQL 模式比较来生成模式的 xSQL 快照并将这些文件添加到您的版本控制中。然后,要恢复或更新到特定版本,只需将数据库的当前版本与目标版本的快照进行比较。
此外,如果您还想将数据置于版本控制之下,您可以使用 xSQL 数据比较为您的数据库生成更改脚本并将 .sql 文件添加到版本控制中。然后,您可以执行这些脚本以恢复/更新到您想要的任何版本。请记住,对于“恢复”功能,您需要生成更改脚本,当执行该脚本时,将使版本 3 与版本 2 相同,而对于“更新”功能,您需要生成执行相反操作的更改脚本。
最后,通过一些基本的批处理编程技能,您可以使用 xSQL Schema Compare 和 xSQL Data Compare 的命令行版本来自动化整个过程
免责声明:我隶属于 xSQL。