1

これは、私がここに投稿した問題への別の突き刺しです。別の方向に進むため、重複して閉じないでください。

データベースの列を別の列の集計で自動的に更新したいと考えています。関連する 3 つのテーブルがあります。

T_RIDER
  RIDER_ID
  TMP_PONYLIST
  ...

T_RIDER_PONY
  RIDER_ID
  PONY_ID

T_PONY
  PONY_ID
  PONY_NAME
  ...

T_RIDERを介しT_PONYてn:m関係を持ちT_RIDER_PONYます。 T_RIDERさらにT_PONYいくつかの列がありますが、ここで関連するのはTMP_PONYLISTandのみです。PONY_NAME

TMP_PONYLISTのセミコロンで区切られたリストです。PONY_NAMES次のようなものを想像してください"Twisty Tail;Candy Cane;Lucky Leaf"。T_RIDER_PONYまたはに何が起こっても、このフィールドを最新の状態に保ちたいと思いT_PONYます。

すべてのアプリケーションはビューでのみ動作し、テーブルに直接アクセスすることはありません。マテリアライズド ビューでこの問題を解決する必要があります。マテリアライズドは、パフォーマンス上の理由から絶対的な要件であり、ビューがコミット時にそれ自体を更新する必要があります。

ビューは次のように作成する必要があります

CREATE MATERIALIZED VIEW
  V_TMP_PONYLIST 
BUILD IMMEDIATE
REFRESH COMPLETE ON COMMIT
AS SELECT 
  ...

For ...この記事の次の集計手法を試しました。

  • WM_CONCAT -> 私の Oracle では利用できません
  • ユーザー定義集計 ->ORA-12054
  • ROW_NUMBER および SYS_CONNECT_BY_PATH ->ORA-12054

私はまだ試していません：

  • 特定の機能
  • 関数 Ref Cursor を使用したジェネリック関数
  • 収集機能

これらのいずれかを具体化されたビューで機能させる機会はありますか、それとも無意味ですか。具体化されたビューで機能する可能性のある他の手法を知っていますか?

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi を使用しています。

4

1 に答える 1

2

ON COMMIT REFRESH JOIN AGGREGATE MATERIALIZED VIEW を作成します。このタイプの MV には多くの制限があります。基本的に、単純な結合、SUM、COUNT、および AVG を超えるものは、すべての DML アクティビティで ON COMMIT-refreshable になりません。

私の意見では、あなたは間違った心の状態でこの問題を解決しようとしています。物理的に問題を解決できるかどうかを知る前に、すでに技術的な道を選んでいるのです。代わりに、利用可能なすべてのツールを調べて、要件を満たす最適なツール (実装/保守が最も簡単なツール) を選択する必要があります。

機能することが知られているオプションが既に与えられています: 複雑なロジック トリガー、単純なビュー、手続き型アプローチ (列ロジックを適切に処理することが知られている、徹底的にテストされ承認された API を介してのみベース テーブルを更新します)。

パフォーマンスの問題のために単純なビューが機能しないことは既に述べました。他のオプションを検討することをお勧めします。トリガーを使用すると、既存のコードを保持できますが、予期しない副作用が多数発生する可能性があります (複雑なトリガーは非常に楽しいものです)。手続き型ロジックはコーディング/保守が最も簡単ですが、実際にそれを使用し、アプリケーションを変更して新しい API を使用する必要があります。API を介してテーブルが更新されるようにするには、ベース テーブルを更新する権限を取り消す必要がある場合があります。

于 2009-11-13T15:09:18.233 に答える