在哪里保存pl/sql常量?

在包体或规范中包含常量的一个缺点是,重新编译包时,在pga中具有包状态的任何用户会话都将获得or a-04068。出于这个原因,在一个大型开发环境中,我们采用了一种约定,即使用单独的spec-only包来保存每个包的常量(以及包globals,如果有的话)。然后我们强加一个规则,说这些仅限规范的包只允许被它们的“拥有”包引用——这是我们在代码评审时强制执行的。这不是一个完美的解决方案,但在当时对我们有效。

出于同样的原因,我从不建议使用一个常量包来规范它们,因为每次有人需要引入新常量或修改现有常量时,所有用户会话都会得到or a-04068。

在许多情况下,您希望将它们保留在规范中,以便其他包可以使用它们,特别是在从包调用函数和过程时将它们用作参数。

只有当你想把它们藏在包裹里的时候,你才应该把它们放在尸体上。

对于那些与任何特定代码片段都不相关,但与整个模式相关的常量,只为常量准备一个包可能是一个好主意。

对于我们的应用程序,所有常量都在一个表中。使用一个简单的函数来提取它们。重新编译没有问题,ora-04068,…

在我看来是最好的选择。将“常量”存储在表中,并创建一个泛型函数来获取值。04068号

默认情况下,我希望常量位于包体中,除非您将常量用作某个公共包过程/函数的参数值或用作函数的返回值。

将常量放入包规范的问题是,如果需要更改常量的类型,则使用常量的其他包可能会失败,因为常量就在那里。如果常量最初是私有的,那么您不需要对每个更改执行影响分析。

如果您需要像默认语言那样存储contants,那么我将把这些contants封装在如下函数中 get_default_language 等等,并保持常量私有。

我担心的是有“一个包来控制常量”,因为包状态——常量、变量和代码——在第一次调用任何公共变量或包时被缓存在用户的pga中。如果包常量是公共的,则它的作用域应该是包,并且只能由包的方法使用。

其作用域跨越包的常数应在具有说明的代码表中,并根据需要加入。毕竟,常量不是变量也不是。拥有一个包含“常量”的键值对表可以使它们全部公开,并使动态更改它们成为可能。