DB リンクを介して別のデータベースにあるパッケージ内のプロシージャを呼び出す場合を除き、別のパッケージ内のプロシージャを呼び出すオーバーヘッドは無視できます。
メモリの問題だけでなく、パフォーマンスの問題もいくつかありますが、それらはまれであり、その中間です。その上、彼らは「オラクルの黒魔術」のカテゴリーに分類されます。たとえば、このリンクを確認してください。それが何であるかを明確に理解できる場合は、自分が熟練したオラクルの専門家であると考えてください。そうでない場合でも、心配する必要はありません。本当にハードコアなものだからです。
ただし、考慮すべきは依存関係の問題です。Oracle パッケージは、specとbodyの 2 つの部分で構成されます
。Specは、パブリックプロシージャと関数 (つまり、パッケージの外部で表示される) が宣言されるヘッダーです。
本体はそれらの実装です。これらは密接に関連していますが、2 つの別個のデータベース オブジェクトです。
Oracle はパッケージ ステータスを使用して、パッケージが有効か無効かを示します。パッケージが無効になると、それに依存する他のすべてのパッケージも無効になります。たとえば、プログラムがパッケージ A のプロシージャを呼び出し、パッケージ B のプロシージャを呼び出す場合、プログラムはパッケージ A に依存し、パッケージ A はパッケージ B に依存することを意味します。Oracle では、この関係は推移的であり、つまり、プログラムはパッケージ B に依存します。したがって、パッケージ B が壊れていると、プログラムも停止します (エラーで終了します)。
それは明らかなはずです。しかし、それほど明白ではありませんが、Oracle はパッケージ仕様を介してコンパイル時に依存関係も追跡します。
パッケージ A とパッケージ B の両方の仕様と本体が正常にコンパイルされ、有効であると仮定しましょう。次に、パッケージ B のパッケージ本体を変更します。仕様は変更せず本体のみを変更したため、Oracle はパッケージ B の呼び出し方法が変更されておらず、何もしないと想定します。
しかし、ボディとともにパッケージ B の仕様を変更した場合、Oracle は、プロシージャーのパラメーターなどを変更した可能性があると推測し、チェーン全体(つまり、パッケージ B と A およびプログラム) を無効としてマークします。Oracle は、仕様が実際に変更されたかどうかを確認せず、timestemp を確認するだけであることに注意してください。したがって、仕様を再準拠してすべてを無効にするだけで十分です。
無効化が発生すると、次にプログラムを実行すると失敗します。しかし、その後もう一度実行すると、Oracle はすべてを自動的に再コンパイルし、正常に実行します。
私はそれが混乱していることを知っています。それがオラクルです。あなたの頭脳をあまりそれに巻き込もうとしないでください。覚えておく必要があるのは、次の 2 つのことだけです。
可能であれば、複雑なパッケージ間の依存関係を避けてください。あるものが別のものに依存し、それが別のものに依存している場合、1 つのデータベース オブジェクトを再コンパイルするだけですべてが無効になる可能性が非常に高くなります。最悪のケースの 1 つは、パッケージ A がパッケージ B のプロシージャを呼び出し、パッケージ B がパッケージ A のプロシージャを呼び出す場合の「循環」依存関係です。
パッケージ仕様とパッケージ本体を別々のソース ファイルに保持します。そして、ボディだけ変えるならスペックに手を加えるな!