数据库对象版本控制（不是模式）答案

【问题标题】：Database objects version control (not schema)数据库对象版本控制（不是模式）
【发布时间】：2026-01-20 19:35:02
【问题描述】：

我试图弄清楚如何在我们有两个 DB 的环境中实现版本控制：一个 Testing 和一个 Production。

在测试中。有任意数量的任务正在测试。这些对操作对象的数量和复杂性没有限制，这意味着我们可以有一个为期 3 天的任务来更改 2 个包主体和一个触发器，我们可以有一个 3 个月的任务来更改 100 个不同的对象，包括С源文件和二进制文件对象。

我主要关心的是数据库的基于文本的对象。我们需要对 Test 和 Production 代码进行版本控制，但是任何任务都可以从 Testing 转到 Production 没有定义随便点。

这意味着现在我们必须手动跟踪文件中的更改，在每个文件中选择代码中从 Testing 到 Production 的行。我们使用了一个非常基本的解决方案，在标头中写入一个带有基于文件的版本号的 cmets 序列，并添加具有该序列的代码标签来分隔更改。

我正在努力实现 SVN，因为我想将 Testing 创建为 Production 的一个分支，在 Testing 中有分支来限制每个任务，但我发现它可能导致许多 Testing 任务在合并期间被移植到 Production。

这就是说，我的问题是：

【问题讨论】：

【解决方案1】：

我使用 SVN 对 DB 脚本进行源代码控制。

我没有针对您的问题的技术解决方案，但我可以解释我们使用的方法。

我们有两组脚本——一组用于增量更改，另一组用于数据库对象和过程的完整声明。

在开发期间，我们仅更新了最终在部署期间使用的脚本中的增量更改。在测试轮次中，我们更新了脚本。最后，在生产环境中运行脚本后，我们更新了包含完整声明的第二组脚本。完整的脚本被用作参考并从头开始创建一个数据库。

【讨论】：

我的问题不在于部署，生产数据库正在运行，我们没有部署任何其他实例。我们只需要消除从测试到生产的合并任务的手工工作。我们一直在测试中进行开发，每周都有新东西进入生产阶段。
我不确定我是否理解这个问题 - 我们也有很多变化 - 我们只是以更改日志的方式进行了更改。每个开发人员都必须将所有更改发送给负责集成和维护更改脚本的 DBA。如果您正在寻找一种自动工具来执行此任务，那么我不知道（如果有的话，我们可能会有更多的失业 DBA）。