使用索引进行变更管理的最佳实践

Question

我们的 IT 车间首先开始建立一批 DBA。我们所有人（包括我自己）都是从应用程序开发/架构领域过来的，所以 DBA 领域对我们来说还很陌生。

除了建立 DBA 小组外，我们还希望在需要移动更改时构建更改管理程序和流程（希望基于最佳实践）。

我发现以下帖子对触发器、存储过程和/或 DDL 更改很有帮助。但它不一定涉及索引或供应商数据库。

我们混合使用了我们自己的数据库和供应商数据库。在我们的案例中，一些供应商（尽管不是全部）正在与我们公司合作构建数据库和应用程序。在我们的应用程序“上线”之前，我们正在对其进行性能测试。因此，我们正在大量分析索引（或缺乏索引）。

当我们遇到我们认为应该创建的索引时，我们如何最好地处理与这些相关的变更管理，包括我们自己的数据库以及任何供应商？

你在你的店里做什么？我对工具的担心比对过程的担心要少。

编辑：到目前为止，我很欣赏这个问题的反馈、评论和答案。我注意到一些答案是特定于工具的。如果可以的话，我正在寻找更多“不可知”的做法。

然而，如果不可知论是不可能的，那么对于工具集，我们主要使用 IBM DB2 LUW（实际上是在 AIX 上）。我们有一些 DB2 on Windows 和 DB2 for i（IBM 的 i5/OS），但我们主要是 AIX DB2。我们确实使用源代码控制，特别是 Subversion。

同样，寻找通用的最佳实践，但以上是我们使用的特定于供应商的方法。

编辑： 当前决定：我们打算跟踪我们的推理以及我们的变化。所以我们将在我们的问题跟踪软件（在我们的例子中是 JIRA）中打开一个问题。现在我们可以在文档中添加更改的优先级、备份更改应该是什么的数据、更改以及来自测试更改的另一个环境的更改结果。

然后，我们还打算跟踪我们在 SVN 中的脚本更改（很像下面建议的那样）。通过这种方式，我们可以跟踪存在于何处的版本。这可以记录在我们的 JIRA 问题中（以及我们使用的任何其他审计软件，即粘贴的链接）。我们可以更确定地知道什么改变了什么环境以及为什么。然后，我们还可以跟踪索引是否是我们在供应商实施之外或在其实施之前添加的内容，等等。）

Answer 1

我强烈建议您像对待应用程序代码一样对待数据库。您可以将数据库脚本化为它的组成部分，并将它们检入源代码管理，然后使用与您的应用程序相同的标签和版本。

要使对象进入源代码管理，您可以使用许多工具。微软有一个绰号为 Data Dude 的工具。它适用于 Visual Studio。他们还准备发布一个名为 SQL Server 数据库工具 (SSDT) 的新工具，同样使用 Visual Studio。我的公司 Red Gate Software 制作了一个与 SSMS 配合使用的工具，称为 SQL 源代码控制。

在流程方面，我为《红门团队开发指南》一书写了好几章。它可以免费下载（或者如果你想杀死一棵树，你可以从亚马逊购买一棵树）。我详细介绍了在那里的开发团队中使用数据库的更多细节。