Estou tentando escrever uma consulta em que preciso calcular o número de visitas de um cliente, cuidando dos dias sobrepostos. Suponha que a data de início do itemID 2009 seja 23 e a data final seja 26, portanto, o item 20010 está entre esses dias, não adicionaremos esta data de compra à nossa contagem total.
Exemplo de Cenário:
Item ID Start Date End Date Number of days Number of days Candidate for visit count
20009 2015-01-23 2015-01-26 4 4
20010 2015-01-24 2015-01-24 1 0
20011 2015-01-23 2015-01-26 4 0
20012 2015-01-23 2015-01-27 5 1
20013 2015-01-23 2015-01-27 5 0
20014 2015-01-29 2015-01-30 2 2
OutPut deve ser de 7 VisitDays
Tabela de entrada:
CREATE TABLE #Items
(
CustID INT,
ItemID INT,
StartDate DATETIME,
EndDate DATETIME
)
INSERT INTO #Items
SELECT 11205, 20009, '2015-01-23', '2015-01-26'
UNION ALL
SELECT 11205, 20010, '2015-01-24', '2015-01-24'
UNION ALL
SELECT 11205, 20011, '2015-01-23', '2015-01-26'
UNION ALL
SELECT 11205, 20012, '2015-01-23', '2015-01-27'
UNION ALL
SELECT 11205, 20012, '2015-01-23', '2015-01-27'
UNION ALL
SELECT 11205, 20012, '2015-01-28', '2015-01-29'
Eu tentei até agora:
CREATE TABLE #VisitsTable
(
StartDate DATETIME,
EndDate DATETIME
)
INSERT INTO #VisitsTable
SELECT DISTINCT
StartDate,
EndDate
FROM #Items items
WHERE CustID = 11205
ORDER BY StartDate ASC
IF EXISTS (SELECT TOP 1 1 FROM #VisitsTable)
BEGIN
SELECT ISNULL(SUM(VisitDays),1)
FROM ( SELECT DISTINCT
abc.StartDate,
abc.EndDate,
DATEDIFF(DD, abc.StartDate, abc.EndDate) + 1 VisitDays
FROM #VisitsTable abc
INNER JOIN #VisitsTable bc ON bc.StartDate NOT BETWEEN abc.StartDate AND abc.EndDate
) Visits
END
--DROP TABLE #Items
--DROP TABLE #VisitsTable
Existem muitas perguntas e artigos sobre intervalos de tempo de embalagem. Por exemplo, Packing Intervals de Itzik Ben-Gan.
Você pode empacotar seus intervalos para o usuário determinado. Uma vez compactado, não haverá sobreposições, portanto, você pode simplesmente somar as durações dos intervalos compactados.
Se seus intervalos forem datas sem horas, eu usaria uma
Calendar
tabela. Esta tabela simplesmente contém uma lista de datas para várias décadas. Se você não possui uma tabela Calendário, basta criar uma:Há muitas maneiras de preencher essa tabela .
Por exemplo, 100 mil linhas (~ 270 anos) de 1900-01-01:
Veja também Por que as tabelas de números são "inestimáveis"?
Depois de ter uma
Calendar
mesa, veja como usá-la.Cada linha original é unida à
Calendar
tabela para retornar tantas linhas quantas forem as datas entreStartDate
eEndDate
.Em seguida, contamos datas distintas, o que remove as datas sobrepostas.
Resultado
Concordo plenamente que a
Numbers
e aCalendar
tabela são muito úteis e se esse problema pode ser muito simplificado com uma tabela Calendar.I'll suggest another solution though (that doesn't need either a calendar table or windowed aggregates - as some of the answers from the linked post by Itzik do). It may not be the most efficient in all cases (or may be the worst in all cases!) but I don't think it harms to test.
It works by first finding start and end dates that do not overlap with other intervals, then puts them in two rows (separately the start and end dates) in order to assign them row numbers and finally matches the 1st start date with the 1st end date, the 2nd with the 2nd, etc.:
Two indexes, on
(CustID, StartDate, EndDate)
and on(CustID, EndDate, StartDate)
would be useful for improving performance of the query.An advantage over the Calendar (perhaps the only one) is that it can easily adapted to work with
datetime
values and counting the length of the "packed intervals" in different precision, larger (weeks, years) or smaller (hours, minutes or seconds, milliseconds, etc) and not only counting dates. A Calendar table of minute or seconds precision would be quite big and (cross) joining it to a big table would be a quite interesting experience but possibly not the most efficient one.(thanks to Vladimir Baranov): It is rather difficult to have a proper comparison of performance, because performance of different methods would likely depend on the data distribution. 1) how long are the intervals - the shorter the intervals, the better Calendar table would perform, because long intervals would produce a lot of intermediate rows 2) how often intervals overlap - mostly non-overlapping intervals vs. most intervals covering the same range. I think performance of Itzik's solution depends on that. There could be other ways to skew the data and it's hard to tell how efficiency of the various methods would be affected.
Essa primeira consulta cria diferentes intervalos de Data de início e Data de término sem sobreposições.
Observação:
id=0
) está misturado com um sample do Ypercube (id=1
)Consulta:
Resultado:
Se você usar esta Data de início e Data de término com DATEDIFF:
A saída (com duplicatas) é:
SUM=7
)SUM=10
)Você só precisa juntar tudo com um
SUM
eGROUP BY
:Resultado:
Dados usados com 2 IDs diferentes:
Acho que isso seria direto com uma tabela de calendário, por exemplo, algo assim:
Equipamento de teste