【发布时间】：2021-07-21 14:39:59
【问题描述】：
我们正在构建一个需要版本控制的自动化流程，以便我们甚至可以在几年后使用某些参数重新运行它。我们一直在讨论实现“版本控制”级别的方法。我们希望以某种形式保留 Oracle 中的版本，以便您可以相对轻松地让它们再次运行。
决定我们需要为不同的版本使用不同的名称，例如 *_1、*_2 等。
我对此有一些担忧。首先，无论更改多么小，都需要努力始终制作新版本的软件包，因此版本的数量很容易失控。其次，您无法知道是否有人接触过该版本，因为它已经创建并针对一组特定的参数运行。 （您可以在 Oracle 表中获取最后更新的日期并与原始运行时间进行比较，但这并不是特别有效，而且您不知道它只是删除了空格还是实际代码更改。）
有没有经过验证的好的替代方案？
【问题讨论】：
-
文件和得到... 文件和差异的版本是自动的。 thatjeffsmith.com/archive/2021/04/…
-
叹气，Git，没有。
-
如果 pack_a_1.0.1 引用的表版本不再有效，例如新的 NOT NULL 列、新触发器等，会发生什么？您不能保证旧版本仍可与最新架构一起使用。所以，关键问题是运行旧版本是否需要数据库结构与旧包版本上次（成功）运行时的结构相同？
-
感谢@thatjeffsmith 的推荐。我们正在使用 git，但此架构保存在安全服务器上，不允许自动连接，这意味着您需要手动复制包。将尝试查看我们如何连接它们，但很可能我们的安全人员不会允许这样做，因为架构包含非常敏感的信息。
-
@TenG 这是一个非常好的问题，而且确实引起了我对这个决定的很多担忧。包状态只是当您想要返回可能几年并且您不想随时冻结相关对象因此寻找替代选项时的问题之一。
标签： oracle version-control package oracle-sqldeveloper plsql-package