2

データベース上のテーブルを更新するための Oracle ストアド プロシージャを作成したいと思います。プロシージャに列名パラメータを与える (または与えない) 方法がある場合、「この列を更新しない」ことを意味します。これは、

テーブル名セットの更新
       columnname = nvl(p_columnname, columnname),
       ...
ここで、キー = p_key

これを行うと、列を null にすることはできません。列も無効にできるようにしたい。Oracle が型なしキーワード UNKNOWN をサポートしていれば、p_columname varchar2 := UNKNOWN と言って、カスタム関数でパラメーターの省略をテストできます。しかし、それがなければ、互換性のないデータ型の比較でエラーが発生しないように、データ型ごとに 1 つずつ、「その列を更新しない」ことを意味する魔法の値を定義するのが難しくなります。

これは非常に一般的な問題のようです (変更していない列に対して書き込み前の読み取り選択を必要とせずに、テーブルへのすべての更新を処理する 1 つのストアド プロシージャ)。確かに、誰かがそれを処理するためのベストプラクティスを見つけました。とにかくそう願っています。前もって感謝します。

4

2 に答える 2

1

ここでは、完全に的を絞った更新を提供する一方で、すべてを更新することで開発を容易にするというバランスを取る必要があります。どちらもパフォーマンスに悪影響を与える可能性があります。

すべての列を更新すると、REDO の増加、UNDO の増加、REDO ログの負荷の増加、ログ ファイルの同期の待機時間の延長、余分な外部キー値チェックの可能性など、明らかにオーバーヘッドが生じます。パフォーマンスの低下は、多くの場合、開発者がトラブルシューティングと再開発。

ただし、一方で、すべての更新が完全に焦点を合わせられている場合、共有プール内の 1 つの更新ステートメントの代わりに、5、10、20 などになる可能性がありますが、変更の多くの組み合わせが可能です。これはそれ自体が悪いことであり、難しい解析が増加し、後のトラブルシューティングで時間が失われる可能性があります。

妥協点は、おそらく、より一般的な種類の更新 (電話番号の変更、注文状況の更新など) を特定して、それら専用の更新を提供し、残り (できれば少数派) を一般的な更新に送信することです。 .

細心の注意を払うために、一般的な更新プログラムを 60 回使用するたびにログを記録して、何が変更されているかを正確に確認し、予期しない一般的な組み合わせ (または開発者が間違った更新 API を使用している) を見つけようとすることを検討してください。

extract(second from systimestamp) < 1

... か何か。

于 2013-05-28T20:04:07.640 に答える