1

クエリで正しい where 述語が常に使用されるよう適切に奨励するために、Oracle の一部の通常のビューに「パラメータ化されたビュー」を重ねることを決定しました。

反復コード (適切に結合されたテーブル) の大部分がビューに表示されるため、共通の結合とフィルターの独自のコピーを使用する多くの異なるプロシージャーと関数を使用する必要がなくなります。

次に、これらのビューにパイプライン化されたテーブル関数をレイヤー化して、ビューが「すべての時間と空間で」呼び出されないように、呼び出し元が必要なフィルターを確実に提供するようにします。私は sys_context と userenv と package 変数を使用する代替案を調べました。それらは Oracle ユーザーがパラメータ化されたビューと呼んでいるように見えますが、ビューが使用されるたびにそれらのシムをビューの周りに配置することは単に実行可能ではなく、再利用できません自己結合します。

StackOverflow を含むさまざまな場所で、これについて多くのことを読みました。

ORACLE 11g のテーブル値関数? (パラメータ化されたビュー)

データベース: パイプライン関数

パイプライン化されたPL/SQL表関数内でSELECTを使用できますか?

これは、多くのクエリが繰り返されて無秩序になったアプリケーションの保守性を改善しようとするアーキテクチャ上の決定です。ビューはある程度は役に立ちますが、呼び出し元に述語を強制して、呼び出し元がばかげたことをするのを止める方法がないのではないかと心配しています。

私は SQL Server でインライン テーブル値関数を使用してこの手法を使用して大きな成功を収めました。コードが少なくなったため、システムの一貫性が大幅に向上し、依存関係と提案された変更の影響を追跡しやすくなりました。 b) より多くの再利用とより少ない繰り返し。

最後のリンクについて少し心配です。これらのパイプライン化されたテーブル関数のいずれかに参加し、それを使用して別のテーブルを更新すると、同時実行性またはタイミングの問題が発生する可能性があることを暗示しているようです。

パイプライン化されたテーブル関数の経験と、私が注意する必要があることを教えてください。また、より良い代替手段がある場合は、あなたの答えでも教えてください。

4

1 に答える 1

3

はい、パイプライン関数内でテーブルをクエリする特定時点の動作は、直接またはビューを介してテーブルをクエリする場合とは異なるため、考慮する必要があります。とはいえ、パイプライン化された関数が頻繁に更新されないテーブルをクエリしている場合、通常は問題になりません。ただし、同時実行性やタイミングの問題は考えられません。

(ビューを使用するのではなく) 開発者が使用するパイプライン化された関数を提供することに関する私の主な問題は、(一部のビューのように) 簡単に誤用される可能性があることです。開発者は、あるパイプライン関数の結果を別の関数に結合することを選択する場合があり、その結果、インデックス、プッシュされた述語、およびテーブルの制約などを利用できない非常に非効率的なクエリが発生します。

保守性が主な問題である場合は、ビューをお勧めします。ビューは、共通の変換を 1 か所で定義し、おそらく共通の結合も定義することで、重複するコードを減らすのに役立ちます。ただし、これらも簡単に誤用されます (たとえば、元のクエリで必要とされていない別のテーブルに結合しているにもかかわらず、ビューに結合する)。

パフォーマンスと効率は、おそらく注意すべき点です。アプリケーション内のすべての SQL に対して厳格なレビュー制度を導入し、不適切に記述されたクエリや一貫性のないクエリを探します。

于 2011-05-13T00:51:39.333 に答える