主页 / dba / 问题 / 64
Accepted
Beth Lang
Asked: 2011-01-04 15:23:26 +0800 CST

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

  • 772

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

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

问题在于它非常手动。它依赖于开发人员记得附加 sql 或如果开发人员忘记了同行评审员来获取它。有时，最终是发现问题的测试人员或 QA 部署人员。

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

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

我非常习惯我的源代码控制系统为我处理这样的事情，并希望我的 SQL 也有同样的事情。

sql-server-2008 process

5 个回答

  1. Best Answer

    在 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 个。

    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 的环境中，您将永远无法访问生产服务器。因此，脚本需要事先明确和练习。更新脚本顶部的注释包括新表、存储过程、函数等的列表以及修改表、存储过程、函数等的列表。如果数据被修改，请解释修改的内容和原因。

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

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

    • 17

  2. 你看过 SQL 源代码控制吗？您可以使用它将 SQL Server 连接到 TFS/SVN/Vault 或 VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

    • 7

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

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

    PowerDesigner 是一个通用的建模工具，不仅支持数据库，因此我们开始使用它来管理需求、创建概念、物理和架构图（OOM 也是）等。基本上，我们使用它来为我们的软件工程过程。

    （我与开发 PowerDesigner 的 Sybase 没有任何关系——我只是想我会把它放在那里）。

    • 4

  4. 数据库幽灵

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

    好处

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

    [4] 对于进行本地更改或为不同环境创建单独的实例特别方便。事实上，我为每个影响数据库的功能或错误创建一个单独的数据库非常容易。

    细节

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

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

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

    • 2

  5. 我知道这对大多数 DBA 来说听起来有点矫枉过正：

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

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

    • 1

相关问题