加入多个父/子记录

Question

我正在对专门研究转接呼叫的 Cisco ICM 数据库进行一些分析。

基本上有一个 ICRCallKey 字段，它是在外围网关为表中记录的每一行生成的唯一编号。我可以通过查看 ICRCallKeyParent 和 ICRCallKeyChild 字段并查看它们是否在 ICRCallKey 字段中包含值来判断呼叫何时转移。

当一个呼叫被多次转移时会变得棘手，因为每个字段中都有一个预期值。

例如，如果一个呼叫已被转接五次，我希望查看数据库中的每一行，以便查看呼叫所经过的路线。这被称为从摇篮到坟墓（出于某种未知原因！），并且可以通过不同的外围设备和用户以及整个呼叫在系统中的总时间等来跟踪呼叫。可能性是无止境！ ;-)

我错过了一种非常简单的方法吗？

SELECT p.AgentSkillTargetID [p_AgentSkillTargetID]
,   p.CallDisposition [p_CallDisposition]
,   p.DateTime [p_DateTime]
,   p.Duration [p.Duration]
,   p.ICRCallKey [p.ICRCallKey]
,   p.ICRCallKeyParent [p_ICRCallKeyParent]
,   p.ICRCallKeyChild [p.ICRCallKeyChild]
,   p.CallTypeID [p_CallTypeID]
,   c.AgentSkillTargetID [c_AgentSkillTargetID]
,   c.CallDisposition [c_CallDisposition]
,   c.DateTime [c_DateTime]
,   c.Duration [c_Duration]
,   c.ICRCallKey [c_ICRCallKey]
,   c.ICRCallKeyParent [c_ICRCallKeyParent]
,   c.ICRCallKeyChild [c_ICRCallKeyChild]
,   c.CallTypeID [c_CallTypeID]
FROM tblTCD [p]
LEFT JOIN tblTCD [c]
ON p.ICRCallKeyChild = c.ICRCallKey
AND p.RouterCallKeyDay = c.RouterCallKeyDay

这是我正在使用的 SQL，下面是输出示例。

p_AgentSkillTargetID p_CallDisposition p_DateTime              p.Duration  p.ICRCallKey p_ICRCallKeyParent p.ICRCallKeyChild p_CallTypeID c_AgentSkillTargetID c_CallDisposition c_DateTime              c_Duration  c_ICRCallKey c_ICRCallKeyParent c_ICRCallKeyChild c_CallTypeID
-------------------- ----------------- ----------------------- ----------- ------------ ------------------ ----------------- ------------ -------------------- ----------------- ----------------------- ----------- ------------ ------------------ ----------------- ------------
90277                29                2010-08-16 08:26:58.113 78          1879479165   NULL               1879479175        7669         94669                30                2010-08-16 02:54:04.077 499         1879479175   NULL               1879479179        15029
90045                28                2010-08-16 08:58:27.623 98          1879479460   NULL               1879479480        7890         104415               28                2010-08-16 08:42:27.067 43          1879479480   NULL               1879479481        15029
89971                29                2010-08-16 09:10:53.110 586         1879479523   NULL               1879479628        7663         97518                29                2010-08-16 09:19:04.583 109         1879479628   NULL               1879479650        23893
74814                28                2010-08-16 09:05:08.577 115         1879479174   NULL               1879479238        19256        92707                7                 2010-08-16 08:33:50.103 2           1879479238   NULL               NULL              7663
80435                28                2010-08-16 09:04:52.577 103         1879479171   NULL               1879479194        19263        94669                30                2010-08-16 04:14:33.077 121         1879479194   NULL               1879479198        15029
88952                29                2010-08-16 09:05:24.033 83          537702168    NULL               537702175         26543        54070                28                2010-08-16 09:43:32.597 784         537702175    NULL               537702344         16016
74783                28                2010-08-16 09:14:11.080 363         1879479324   NULL               1879479379        19856        102341               29                2010-08-16 09:19:27.600 1859        1879479379   NULL               1879479809        7669
89161                29                2010-08-16 09:10:45.540 151         537702198    NULL               537702212         16094        103369               29                2010-08-16 09:40:35.593 412         537702212    NULL               537702257         25507
74708                29                2010-08-16 09:20:09.083 707         1879479331   NULL               1879479487        10216        99954                7                 2010-08-16 08:58:50.623 2           1879479487   NULL               NULL              7663
100868               29                2010-08-16 09:10:43.540 113         537702204    NULL               537702219         26543        70678                29                2010-08-16 09:36:46.590 55          537702219    NULL               537702226         20067

如您所见，我在p.ICRCallKeyChild = c.ICRCallKey 上有一个基本的加入。如果呼叫再次转移，那么c_ICRCallKeyChild 中将有一个号码，然后会以与第一次加入相同的方式加入tblTCD。

我希望看到类似以下（虚构）的结果：

CallReference CallTransferCounter AgentSkillTargetID CallDisposition DateTime                Duration CallTypeID
------------- ------------------- ------------------ --------------- ----------------------- -------- ----------
1             1                   90277              29              2010-08-06 08:26:58.113 78       7699
1             2                   90045              30              2010-08-06 08:28:56.445 345      5467
1             3                   7786               13              2010-08-06 08:34:34.243 445      4355
2             1                   78973              13              2010-08-06 09:14:34.423 43       3342

这更有意义吗？我希望 CallReference 会随着每个新呼叫而增加，但 CallTransferCounter 会随着每个转移呼叫而增加 IE 存在父/子关系。

Answer 1

您需要查看Common Table Expressions，尤其是Recursive 选项。

第二个链接的伪代码：

WITH cte_name ( column_name [,...n] )
AS
( 
CTE_query_definition –- Anchor member is defined.
UNION ALL
CTE_query_definition –- Recursive member is defined referencing cte_name.
)
-- Statement using the CTE
SELECT *
FROM cte_name

如果您能回答我在您的问题中添加的问题，我或许可以发布一些更接近您实际需要的代码。目前，我不确定如何构建锚查询，因为不清楚如何识别（超级）父行。我希望它是没有 ICRCallKeyParent 值的行，但您的示例输出不支持该概念。