ホリスティックSQLクエリ（Oracle PLSQL内）およびUX

Question

全体的なSQLクエリでエラーを処理する方法について質問があります。私たちはOracle PL/SQLを使用しています。私たちのコードベースの大部分は行ごとの処理であり、パフォーマンスが極端に低下します。私が知る限り、その最大の問題は、PL/SQLとSQLエンジン間のコンテキスト切り替えです。

問題は、ユーザーが何が問題になったのかわからないということです。データが存在する場合ERRORMSGを示さない場合

はデータ

火が第二（カウント）を選択することを選択、別のテーブルにいくつかのデータ上記

• カーソル
• 火SELECT（カウント）：オールド・スタイルは次のようになりますERRORMSG表示されていない場合であれば、データは、存在する別のテーブルに
• は、データ
• は、他のいくつかのテーブルを変更することを選択

それは10-20のテーブルのために続くことができます。これは基本的にはCプログラムによく似ています。

UPDATE (
    SELECT TAB1.Status, 
     10 AS New_Status 
    FROM TAB1 
    INNER JOIN TAB2 ON TAB1.FieldX = TAB2.FieldX 
    INNER .. 
    INNER .. 
    INNER .. 
    INNER .. 
    LEFT .. 
    LEFT .. 
    WHERE TAB1.FieldY = 2 
    AND TAB3.FieldA = 'ABC' 
    AND .. 
    AND .. 
    AND .. 
    AND .. 
) TAB 
SET TAB.Status = New_Status 
WHERE TAB.Status = 5; 

このような全体的なSELECTは、非常に多くの処理を高速化します。私はそのようなクエリをいくつか変更しました。そのものは5時間から3分に下がりましたが、それは人間とのやりとりのないサービスだったので、やや簡単でした。

質問誰かが何らかのフォームを入力して応答を待っているようなものをどうやって処理するのですか？だから何かが間違っていたら、彼らはエラーが必要です。私の心に来た解決策は、行が更新されたかどうかをチェックすることでした。別のコードセクションにジャンプしても、そのエラーを確定するためにすべての単一の選択が行われます。しかし、すべての変更の後、全体選択とすべての単一選択を更新する必要があります。時間がたつと推測され、彼らは異なっていて、より多くの問題につながります。

もう1つの解決策は、1日に100回の呼び出しにつながる一般的なerrormsgであり、50個の変数をクエリに置き換えて、where条件/ joinを実行して、必要な行をフィルタリングした条件を見つけ出します。

ここで、パフォーマンスを得るには適切なアプローチはありますが、やはりユーザーフレンドリーな方法です。現時点では、システムは使えないほど遅いと感じています。ボタンを押すと、しばしば長い時間（通常3〜10秒、さらに複雑な作業では5分）待たなければなりません。

Answer 1

大量のデータの場合、セットベースの操作は行ベースの操作よりも高速です。しかし、セットベースの操作は主にバッチタスクに適用されます。 UIタスクは、通常、行ごとに少量のデータを処理します。

あなたの本当の目的は、あなたの個人的な陳述がなぜそんなに長くかかるのかを理解することであるようです。

明確に容認できないです

「ボタンを押すと、あなたは、多くの場合、長い時間（一部complexerタスクに通常3-10秒5分を待たなければならない」。同様に明確にそれが私たちのためにことはできませんそれを説明するために、体系的なパフォーマンスの問題を診断するためのアクセスやドメインの知識はありません。おそらく、現場のコンサルタントを数日間務めるように上司を説得する必要があります。

しかし、ここでは探検する道があります：ロック。

「同じデータを扱う他の多くの人々、状態が重要であるので、」

はたぶん、あなたの問題は、クエリが遅いことによるものではないですが、共有リソースを待機しに関する記述を更新しますか？もしそうなら、より良い（すなわち悲観的な）ロック戦略が役立つかもしれない。

データ構造がアルゴリズムを決定

---

は、「私は人々がより多く知っている必要はありませんと言う理由です」。ビジネスドメインの特質とそのデータの格納方法は、実行コードを書く上で重要です。検索に20のテーブルが含まれているのはなぜですか？これらのテーブルでクエリを実行するのに時間がかかるのはなぜですか？ STORAGE_BIN_IDはこれらすべてのテーブルの主キーではありませんか？

また、ユーザーが個々のビンに必要なバーコードをスキャンするのはなぜですか？ビンの基準を指定する方が効率的であると思われ、セットベースのクエリはその場所に最も近いマッチを割り当てることができます。

多分、複数のユースケースを解決するために1つのクエリを書こうとしていますか？