在另一个Oracle包中调用过程/函数的开销

把它放在一个地方,然后从多个地方调用它——这是基本的代码重用。从一个包调用另一个包的任何开销都是很小的。如果他们仍然对此表示怀疑,请让他们演示性能差异。

担忧者完全可以通过演示性能开销来证明其担忧的有效性。这应该是微不足道的。

同时,他们应该考虑在多个地方重复代码的内存使用和维护开销。

通用代码放在一个包中。

不同数据库 在DB链路上,调用另一个包中的过程的开销可以忽略不计。

有一些性能问题和内存问题,但它们非常罕见。此外,它们属于“甲骨文黑魔法”类别。例如,检查 this link . 如果你能清楚地理解这一点,那么就把自己看作是一个有成就的甲骨文专业人士。如果没有-不要担心,因为这是非常核心的东西。

然而,你应该考虑的是依赖性的问题。 Oracle软件包由两部分组成: 规格 身体 : 是标题,其中 公众的 声明过程和函数(即,在包外部可见)。 这就是它们的实施。 虽然联系紧密,但它们是2 分离 数据库对象。

依赖它的也会变得无效。 例如,如果您的程序调用包a中的一个过程,它调用包B中的一个过程,这意味着 取决于 您的程序依赖于包B。因此,如果包B损坏,您的程序也会停止(以错误终止)。

这应该是显而易见的。但不太明显的是,Oracle还通过包规范跟踪编译期间的依赖关系。

Oracle假定调用包B的方式没有改变,也没有做任何事情。

程序参数之类的,还有标记 整个链条 无效(即包B和包A以及您的程序)。 请注意,Oracle不会检查规范是否真的更改,它只是检查timestemp。因此,只需重新组合规范就足以使所有内容无效。

我知道这很令人困惑。那是甲骨文。不要试图把你的大脑太多地围绕它。 你只需要记住几件事:

• 那么,通过只重新编译一个数据库对象而使所有内容无效的概率非常高。 最糟糕的情况之一是“循环”依赖关系,即包A调用包B中的过程,包B调用包A中的过程。 在这种情况下,几乎不可能在不阻止另一个的情况下编译一个。

• 将包装规格和包装体保存在包装箱中 源文件。如果你只需要更换车身,不要触碰规格!