开发人员是否有遵循“最佳实践”类型的流程来进行数据库更改？

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

将更改写在SQL文件中，并将其附加到TFS工作项中。
工作经过同行评审
准备好工作时要进行测试，然后在QA上运行SQL。
工作已通过质量检查（QA）测试。
准备好进行生产时，则在生产数据库上运行SQL。

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

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

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

我已经非常习惯于我的源代码控制系统来处理类似这样的事情我，并希望我的SQL具有相同的功能。

#1 楼

在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 W中的3W。

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

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

例如，“ patch 17”的“ begin patch”插入看起来像：

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，函数等的列表。如果数据被修改，请说明正在修改的内容以及原因。

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

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

#2 楼

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

谢谢，我只是看了一点。如果我们不喜欢db项目在VS中的工作方式，那么红门听起来是一个不错的解决方案。

–贝丝·怀特泽尔
2011年1月11日在18:04

#3 楼

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

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

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

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

#4 楼

DB Ghost

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

数据库中的所有对象均已存储作为源代码管理中的脚本。
您也可以编写“静态数据”（查找表数据）的脚本。
您可以手动更新源代码控制，也可以编写“模型”开发数据库的脚本。
您可以从源代码管理中的脚本（包括静态数据）快速构建数据库。
您可以将更改部署到数据库实例，包括任何生产实例：

您可以将“创建数据库”（通过脚本创建）与现有数据库进行比较，并生成更改脚本。
您可以指示DB Ghost在数据库的两个实例之间自动同步更改，例如构建数据库和生产数据库。

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

详细信息

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

能够将数据库作为一组（一组）脚本和快速创建新实例的能力还在于，对重要数据库代码进行单元测试非常容易（也很有趣）。我使用tSQLt进行单元测试。

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

#5 楼

我知道这对大多数DBA来说听起来有些过分：

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

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

编程黑洞网