我们的 IT 车间首先开始建立一批 DBA。我们所有人（包括我自己）都是从应用程序开发/架构领域过来的，所以 DBA 领域对我们来说还很陌生。
除了建立 DBA 小组外，我们还希望在需要移动更改时构建更改管理程序和流程（希望基于最佳实践）。
我发现以下帖子对触发器、存储过程和/或 DDL 更改很有帮助。但它不一定涉及索引或供应商数据库。
我们混合使用了我们自己的数据库和供应商数据库。在我们的案例中，一些供应商（尽管不是全部）正在与我们公司合作构建数据库和应用程序。在我们的应用程序“上线”之前，我们正在对其进行性能测试。因此，我们正在大量分析索引（或缺乏索引）。
当我们遇到我们认为应该创建的索引时，我们如何最好地处理与这些相关的变更管理，包括我们自己的数据库以及任何供应商？
你在你的店里做什么？我对工具的担心比对过程的担心要少。
编辑：到目前为止，我很欣赏这个问题的反馈、评论和答案。我注意到一些答案是特定于工具的。如果可以的话，我正在寻找更多“不可知”的做法。
然而，如果不可知论是不可能的，那么对于工具集，我们主要使用 IBM DB2 LUW（实际上是在 AIX 上）。我们有一些 DB2 on Windows 和 DB2 for i（IBM 的 i5/OS），但我们主要是 AIX DB2。我们确实使用源代码控制，特别是 Subversion。
同样，寻找通用的最佳实践，但以上是我们使用的特定于供应商的方法。
编辑： 当前决定：我们打算跟踪我们的推理以及我们的变化。所以我们将在我们的问题跟踪软件（在我们的例子中是 JIRA）中打开一个问题。现在我们可以在文档中添加更改的优先级、备份更改应该是什么的数据、更改以及来自测试更改的另一个环境的更改结果。
然后，我们还打算跟踪我们在 SVN 中的脚本更改（很像下面建议的那样）。通过这种方式，我们可以跟踪存在于何处的版本。这可以记录在我们的 JIRA 问题中（以及我们使用的任何其他审计软件，即粘贴的链接）。我们可以更确定地知道什么改变了什么环境以及为什么。然后，我们还可以跟踪索引是否是我们在供应商实施之外或在其实施之前添加的内容，等等。）
我所说的一切都与关系数据库，特定的 MySQL 相关。
我在一个数据库中有许多表，对于其中一些，我想要在记录值更改时存储记录值的历史记录。我已经看到这以几种不同的方式完成：
这些不同的记录历史存储方法有哪些优缺点？还有其他我没有想到的方法吗？
我现在研究了很长时间（大约两个月），还没有找到一个好的方法，所以我会请教各位专家，希望能有所启发。
我在云中运行了一个非常传统的 LAMP Web 应用程序。源代码是使用 Git 进行 VCS 处理的，以及数据库架构（拆分 SQL 文件用于结构和默认数据）。
部署新环境是一种乐趣，无论是开发还是生产。开发环境使用 Vagrant 以及我编写的一些不错的 shell 配置脚本进行部署。生产环境是使用 Vagrant 配置脚本的一个子集部署的，这也很容易做到。
当开发周期对 SQL 模式（结构或数据）进行更改时，事情开始出现问题。在这种情况下，开发人员会更改核心 SQL 脚本，以便所有更改都进入 VCS，这对于全新的环境来说是完全没问题的。
问题出在已经部署的生产环境中：对于那些，我必须手动获取 SQL 更改的所有补丁，因为修订版首先在所有生产服务器中实际运行，以便我可以在之后手动应用它们。这需要很长时间才能发生，是一项非常脆弱且容易出错的任务。
最初，我认为我可以将 SQL 更改从核心 SQL 文件的较小子集移开，让核心 SQL 文件作为起点。当 SQL 结构发生变化时，我可以告诉开发人员创建一个新的 SQL 文件，其中仅包含该开发周期中的更改。
因此，例如：
- structure_begin.sql: the SQL schema as it is now.
|- structure_devcycle1.sql: first set of changes to the structure
|- structure_devcycle2.sql: second set of changes to the structure, and so forth...
然后，通过使用 Git 钩子，我可以有选择地自动将它们部署到生产环境中。但我不知道这是否是一个好方法。在这里我可以问：