我们不存储数据库模式，而是存储对数据库的更改。我们所做的是存储模式更改，以便为数据库的任何版本构建更改脚本，并将其应用于客户的数据库。我写了一个数据库实用程序，它与我们的主应用程序一起分发，它可以读取脚本，并知道需要应用哪些更新。它还具有足够的智能，可以根据需要刷新视图和存储过程。

为了更快地将数据转储到源代码控制系统，您可以使用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脚本生成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

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

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

使用更改脚本将数据库脚本保存到版本控制中是一种好方法，这样您就可以升级您拥有的任何一个数据库。此外，您可能希望保存不同版本的模式，这样就可以创建完整的数据库，而不必应用所有的更改脚本。处理脚本应该是自动化的，这样您就不必做手工工作了。

我认为为每个开发者提供一个独立的数据库，而不是使用一个共享的数据库是很重要的。这样，开发人员就可以独立于其他开发人员创建测试用例和开发阶段。

自动化工具应该具有处理数据库元数据的方法，这些元数据可以告诉您哪些数据库处于何种开发状态，哪些表包含版本可控数据等等。

每个推荐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.

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

项目的一些特点:

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

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