什么是将数据库更改从开发环境迁移到质量保证到生产环境的好方法？目前，我们：

1. 在SQL文件中编写更改脚本，并将其附加到TFS工作项。
2. 这项工作经过同行评审
3. 当工作准备好进行测试时，SQL将在QA上运行。
4. 这项工作已经过质量检查
5. 当工作准备好进行生产时，SQL将在生产数据库上运行。

问题在于这是非常手动的。它依赖于开发人员记住附加的sql或由开发人员忘记的peer-reviewer来捕获它。有时，最终是发现问题的测试人员或QA部署人员。

第二个问题是，如果两个单独的任务更改同一数据库对象，则有时最终需要手动协调更改。这可能只是事实，但似乎仍然应该有一些自动方式来“标记”这些问题或其他内容。

我们的设置：我们的开发车间充满了具有丰富数据库经验的开发人员。我们的项目非常面向DB。我们主要是.NET和MS SQL商店。当前，我们正在使用MS TFS工作项来跟踪我们的工作。这对于代码更改非常方便，因为它将更改集链接到工作项，因此我可以准确地找到在迁移到质量检查和生产环境时需要包括哪些更改。我们目前不使用数据库项目，但将来可能会切换到该项目（也许是答案的一部分）。

我非常习惯于我的源代码控制系统来照顾这样的事情，并且希望我的SQL拥有相同的事情。

在VS环境中，我一直使用数据库项目来实现更新脚本。我倾向于为脚本使用诸如“ DatabaseUpdate17.sql”或“ PriceUpdateFebruary2010.sql”之类的难以想象的名称。将它们作为数据库项目使我可以将它们与Team Server任务，错误（如果我们进行了代码审查，也与它们）联系在一起。我还在每个数据库（我拥有权限）中都包含一个专门用于收集模式更改的表。

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

好吧，这照顾了6 Ws中的3 Ws。

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

我包括一个插入语句，用于记录补丁程序的开始和结束。补丁程序之外发生的事件值得我们关注。

例如，“补丁17”的“开始补丁”插入看起来像：

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

由于它也可以在重建索引时捕获，因此您需要每个月左右运行以下操作来清除这些事件：

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

先前发布在Server Fault上的早期版本。

在符合SOX和PCI-DSS的环境中，您将永远无法访问生产服务器。因此，脚本需要事先清除并执行。更新脚本顶部的注释包括新表，存储的proc，函数等的列表以及已修改表，存储的proc，函数等的列表。如果数据被修改，请说明正在修改的内容以及原因。

第二个问题是，如果两个单独的任务更改同一数据库对象，则有时最终需要手动协调更改。这可能只是事实，但似乎仍然应该有一些自动方式来“标记”这些问题或其他内容。

我从来没有遇到过可以自动跟踪的工具。以前的雇主使用“数据库所有者”的原则-只有一个人亲自负责数据库。这个人不是唯一使用该数据库的开发人员，而是所有更改都必须经过他们。这样可以很好地防止更改相互冲突和破坏。

您是否看过SQL Source Control？您可以使用它将SQL Server连接到TFS / SVN / Vault或VSS- http://www.red-gate.com/products/sql-development/sql-source-control/

另一个解决方案是使用PowerDesigner，ERWin等工具来设计和管理对数据库的更改。

我们开始过渡到在PowerDesigner中对数据库建模的策略。对数据库结构/代码的所有更改都在模型中完成，检入源代码管理，然后从模型中生成更改脚本以实现数据库中的更改。这些更改脚本也已签入到源代码管理中。重大更改都经过同行评审，PowerDesigner使用内置功能使此操作变得非常容易。

PowerDesigner是一个通用的建模工具，不仅支持数据库，因此我们开始使用它来管理需求，创建概念图，物理图和体系结构图（也包括OOM）等。基本上，我们正在使用它为我们的骨干网提供基础软件工程过程。

（我绝不隶属于开发PowerDesigner的Sybase，只是以为我会把它扔在那里）。

DB幽灵

DB Ghost是我最喜欢的数据库管理工具。

好处

1. 数据库中的所有对象都作为脚本存储在源代码管理中。
2. 您也可以编写“静态数据”（查找表数据）的脚本。
3. 您可以手动或通过编写“模型”开发数据库脚本来更新源代码管理。
4. 您可以从源代码管理（包括静态数据）中的脚本（快速）构建数据库。
5. 您可以将更改部署到数据库实例，包括任何生产实例：
   • 您可以将“创建数据库”（通过脚本创建）与现有数据库进行比较，并生成更改脚本。
   • 您可以指示DB Ghost自动同步数据库的两个实例之间的更改，例如，构建数据库和生产数据库。

[4]对于进行本地更改或为不同环境创建单独的实例特别方便。实际上，我很容易为要处理的所有功能或错误创建一个单独的数据库，这些功能或错误都会影响数据库。

细节

与维护显式更改或迁移脚本相比，使用它的主要优点是您几乎不需要维护显式更改或迁移脚本–您几乎只能维护数据库的“当前版本”。管理迁移脚本的一个令人讨厌的方面是，没有简单的方法可以查看，例如，表中的列列表（基于迁移脚本）。当然，需要作为显式迁移进行一些更改，但是它们很容易作为单独的脚本进行处理。

能够作为一组脚本来管理数据库并且能够快速创建新实例的一个特别好的结果是，对重要数据库代码进行单元测试非常容易（也很有趣）。我使用tSQLt进行单元测试。

我只希望其他DBMS具有类似的工具。

我知道这对大多数DBA来说都是过分的：

您是否考虑过使用Ruby on Rails跟踪数据库更改（并且仅跟踪数据库更改）。您不需要运行任何应用程序或编写任何ruby代码等。但是我发现迁移的样式（这就是他们所说的）非常有用：http : //guides.rubyonrails.org/migrations.html

还支持Sql Server，尽管您可能必须使用JRuby + JDBC。