0

我有这张 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 在前一种情况下将为空，而在后一种情况下它将具有直接父级的 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 的“处理中”。“处置”没有。

像这样，所有百万个案例都将被分析并以表格格式放入相应的选项卡中。

我期望的是：根据上述条件，应将各个办公室的百万案例分类并显示为适当的标签（新鲜，正在处理，处置）。

我的问题：我应该使用什么样的表结构或查询来进行这种分析，时间和成本最低？我已经了解了各种可用的技术——嵌套集、Connect By...Prior 等。但我仍然不知道他们对我的问题的可行性。

4

0 回答 0