私はこのテーブル RC_CHAT を持っています:-
REFERRAL_ID BY_OFFICE TO_OFFICE STATUS_ID STATUS_DATE CHAT_ID PARENT_CHAT_ID
R1 KL12 KL11 3 05-01-14 C1
R1 KL12 KL13 3 06-01-14 C2
R1 KL13 KL01 3 07-01-14 C3
R1 KL11 KL12 1 08-01-14 C4 C1
R2 KL11 M001 3 09-01-14 C5
R2 M001 M002 3 10-01-14 C6
R2 M002 KL12 3 11-01-14 C7
R2 M002 M001 3 11-01-14 C8 C6
R2 M001 KL11 3 11-01-14 C9 C5
このシナリオでは、さまざまなオフィスが連絡を取り合い、議論し、決定 (GRANT/DENY) する関連するケース (それぞれのケースは REFERRAL_ID によって一意に識別されます)。CHAT_ID は、大文字と小文字に関係なく、すべての返信で一意です。オフィスは、新しいメッセージとして返信することも、以前の返信に対する返信として返信することもできます。PARENT_CHAT_ID は前者の場合は null になりますが、後者の場合は直接の親の CHAT_ID になります。
私のアプリケーションの目的は、ログイン時にオフィスが関与するすべてのケースをそのオフィスに表示することです。ここでの問題は、数百万のケースがあり、数百万の応答に乗算されることです。そのため、ユーザー アクセスと双方向性を容易にするために、エンド ユーザーの頭痛の種にならないように、すべてのケースを適切に修正できるようにケースを整理および分類する必要があります。
I have currently organized the cases into:-
1. Fresh (A case on which no reply has been posted by an office)
2. Under Process (A case on which a reply has been posted by an office but not granted/denied)
3. Disposed (A case which is granted/denied by an office). [STATUS_ID=1(Grant)/2(Deny)]
P.S.:- 3-Normal Message
条件:- ある時点でのケースは、異なるオフィスの異なるタブに表示されます。
上記の例では、ケースR1は次の場所に表示されます。- KL01 の場合は「フレッシュ」。KL12、KL13は「進行中」。KL11の「処分」。
ケースR2は次のように表示されます:- KL12 の「フレッシュ」。M001、M002、KL11の「処理中」。なしの「処分」。
このように、100 万件すべてのケースを分析し、表形式でそれぞれのタブに入れます。
私が期待すること:上記の条件に従って、100 万件ほどのケースがさまざまなオフィス用に適切なタブ (新鮮、処理中、廃棄済み) に分類されて表示される必要があります。
MY QUESTION:この分析を可能にするには、どのようなテーブル構造またはクエリを使用すれば、時間とコストを最小限に抑えることができますか? ネスティング セット、Connect By...Prior など、利用可能なさまざまな手法を試してきました。しかし、私の問題に対する実現可能性についてはまだわかりません。