2010-08-24 45 views
0

我正在對Cisco ICM數據庫進行一些分析,專門查看轉接呼叫。加入多個父/子記錄

基本上有一個ICRCallKey字段,它是在外圍網關爲表中記錄的每一行生成的唯一編號。通過查看ICRCallKeyParent和ICRCallKeyChild字段並查看它們是否在ICRCallKey字段中包含值,我可以知道何時傳送了一個調用。

問題在於,當呼叫轉移超過一次時,因爲每個字段中都有一個值,就像預期的那樣。

例如,如果一個呼叫已經被轉移五次,我希望看到數據庫中的每一行,這樣我就可以看到呼叫所採用的路線。這叫做cradle-to-grave(出於某種未知的原因!),並且可以通過不同的外設和用戶跟蹤呼叫以及整個呼叫在系統中的總時間等等。可能性是無止境! ;-)

我錯過了一個很簡單的方法嗎?

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遞增而存在父/子關係。

+0

實際上是ICRCallKeyParent實際上已填充(它似乎不是基於您的示例輸出)? – 2010-08-24 07:12:33

+0

這有點奇怪,因爲我發現你可以將p.ICRCallKeyChild加入到c.ICRCallKey中,但是p.ICRCallKey不會加入到c.ICRCallKeyParent中。我使用了這個連接,因爲在這個系統中它獲得了我正在尋找的結果。 – 2010-08-24 07:21:28

回答

0

你會想看看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值的行,但是您的示例輸出不支持該概念。

+0

我可以看到它的第一個唯一方法是通過按順序排列的RouterCallKeyDay和RouterCallKey。一旦一條記錄沒有ICRCallKeyChild,它就會正常結束,其呼叫處置爲13,並被回答。呼叫處置28,29和30是轉移呼叫的各個階段。 – 2010-08-24 07:23:28

+0

如果所有這些轉移鏈都以一個處置爲13的調用結束,那麼我們可能會更好地向後建立列表 - 讓您的錨查詢查詢具有處置權13的調用,然後讓遞歸成員標識這些父項調用。 – 2010-08-24 07:28:05

+0

問題是,他們並不是都以這種性格終止。有可能的負載不同的排列。理想情況下13是我們的目標,但並非總是可能。 – 2010-08-24 07:40:19