Что еще требовалось из выборки из 100? - PullRequest
0 голосов
/ 02 ноября 2009

Я выполняю некоторую работу в системе захвата спроса на входящие вызовы, где с каждым вызовом может быть связано одно или несколько требований.

Существует таблица CaptureHeader с CallDate, CallReference и CaptureID и таблица CaptureDemand с CaptureID и DemandID.

EDIT:
Я добавил некоторые репрезентативные данные, чтобы показать, что ожидается в каждой таблице.

CaptureHeader

CaptureID | CallReference | CallDate
-----------------------------------------------
1         | 1             | 2009-11-02 20:37:00
2         | 3             | 2009-11-02 20:37:05
3         | 2             | 2009-11-02 20:37:10
4         | 4             | 2009-11-02 20:38:00
5         | 5             | 2009-11-02 20:38:30

CaptureDemand

DemandID | CaptureID | DemandText
------------------------------------
1        | 1         | Fund value
2        | 2         | Password reset
3        | 2         | Fund value
4        | 3         | Change address
5        | 3         | Fund value
6        | 3         | Rate change
7        | 3         | Fund value
8        | 4         | Variable to fixed
9        | 4         | Change address
10       | 5         | Fund value
11       | 5         | Address change

Использование приведенных выше таблиц фильтра «Стоимость фонда» вернуло бы ссылки на вызовы 1, 2, 3, 3, 5, потому что 3 имеет две стоимости фонда.

Если бы я сделал DISTINCT по этому поводу, потому что я заказал по дате, он попросил бы меня показать то, что также дало бы мне две строки для 3.

Чтобы получить полный набор данных, я бы сделал следующий запрос:

SELECT * FROM CaptureHeader AS ch
JOIN CaptureDemand AS cd ON ch.CaptureID = cd.CaptureID
JOIN DemandDetails AS dd ON cd.DemandID = dd.DemandID

Хотелось бы получить последние 100 заголовков по дате для конкретного запроса. Это становится сложнее, когда существует более одного и того же требования к заголовку для конкретной ссылки, что возможно.

Я хотел бы получить 100 уникальных ссылок на вызовы, потому что мне нужно вернуть все требования для этих ссылок на вызовы, а затем посчитать, сколько запросов друг друга было также записано в том же вызове.

EDIT:
Я хотел бы иметь возможность сказать «ГДЕ DemandID = SomeValue», чтобы выбрать мои 100 ссылок.

Другими словами, из 100 «запрашиваемая стоимость» требует того, что еще было запрошено. Если это не имеет смысла, дайте мне знать, и я постараюсь изменить вопрос, чтобы он был более понятным.

Я бы хотел получить таблицу, подобную этой:

Demands          | Count
------------------------
Demand asked for | 100
Another demand   |  36
Third demand     |  12
Fourth demand    |   6

Ура, Ян.

Ответы [ 2 ]

1 голос
/ 02 ноября 2009

Теперь, когда примеры данных сделали ваше требование более четким, я полагаю, что следующее, как правило, удовлетворит ваши потребности. По сути, это то же самое, что и предыдущая отправка, с дополнительным условием для JOIN; это условие по существу исключает любую строку CaptureDemand, для которой мы легко имеем тот же DemandText (в том же Capture), сохраняя только ту, которая имеет самый низкий DemandId.

WITH myCTE (CaptId, NbOfDemands)
AS (
  SELECT CaptureID, COUNT(*)  -- Can use COUNT(DISTINCT DemandText)
  FROM CaptureDemand
  WHERE CaptureID IN 
    (SELECT TOP 100 C.CaptureID 
     FROM CaptureHeader C
     JOIN CaptureDemand D ON C.CaptureID = D.CaptureID
        AND NOT EXISTS (
           SELECT * FROM CaptureDemand X
           WHERE X.CaptureId = D.CaptureId AND X.DemandText = D.DemandText
              AND X.DemandId < D.DemandId
        )
     WHERE D.DemandText= 'Fund Value'
     ORDER BY CallDate DESC)
)

SELECT NbOfDemands, COUNT(*)
FROM myCTE
GROUP BY NbOfDemands
ORDER BY NbOfDemands

Что обеспечивает этот запрос: Количество захватов, у которых было ровно одно требование Количество захватов, которые имели ровно два требования .. Количество захватов, которое имело ровно n требований

Для 100 НАИБОЛЕЕ ПОСЛЕДНИХ захватов, которые включали в себя требование определенного значения 'someValue' (и на этот раз, действительно, давая 100, т.е. не считая один и тот же CaptureID дважды в случае дублирования типа запроса).

Несколько баллов:

  • Возможно, вы захотите использовать COUNT (DISTINCT DemandText) вместо COUNT (*) в списке выбора CTE. (Мы включаем 100 различных идентификаторов CaptureID, то есть, что Capture # 3 в вашем образце не появляется дважды и, следовательно, скрывает еще один захват в конце списка, но нам нужно знать, следует ли считать этот Capture # 3 как 3 требования или захват 4 Требований).
  • Упс, не совсем то, что вам нужно, потому что в каждой строке указано количество экземпляров Capture, которые имеют точно это количество требований ...
  • использовать CASE для NbOfDemands, чтобы отобразить текст как в вопросе (тривиально)
  • Это может показать экземпляры Capture с более чем 4 требованиями, но это, вероятно, плюс (если есть), но это, вероятно, плюс
  • Это не будет показывать 0, если, например, не было экземпляров Capture с заданным количеством требований.
0 голосов
/ 03 ноября 2009

Похоже, вы пытаетесь решить проблему Многие ко многим всего с двумя таблицами, и вам действительно нужны три таблицы. Например:

СТОЛ Звонки

CallId | CallDate
----------------------------
1      | 2009-11-02 20:37:00
2      | 2009-11-02 20:37:05
3      | 2009-11-02 20:37:10
4      | 2009-11-02 20:38:00
5      | 2009-11-02 20:38:30

ТАБЛИЦА запросов

RequestId | RequestType
----------------------------
1         | Fund value
2         | Password reset
3         | Change address
4         | Rate change
5         | Variable to fixed

TABLE CallRequests (разрешает множество ко многим)

CallId |RequestId
-----------------
1      |1        
2      |2      
2      |1      
3      |3      
3      |1      
3      |4
3      |1
4      |5
4      |3
5      |1
5      |3    

Эта структура данных позволит вам выполнять запросы со стороны вызовов и со стороны запросов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...