Você conhece uma maneira fácil de gerar um registro para cada hora das últimas 12 horas?

Eu tenho um relatório que mostra a contagem de eventos nas últimas 12 horas, agrupada por hora. Parece fácil, mas estou lutando com como incluir registros que cubram as lacunas.

Aqui está uma tabela de exemplo:

Event
(
  EventTime datetime,
  EventType int
)

Os dados são assim:

  '2012-03-08 08:00:04', 1
  '2012-03-08 09:10:00', 2
  '2012-03-08 09:11:04', 2
  '2012-03-08 09:10:09', 1
  '2012-03-08 10:00:17', 4
  '2012-03-08 11:00:04', 1

Preciso criar um conjunto de resultados que tenha um registro para cada hora das últimas 12 horas, independentemente de haver eventos durante essa hora ou não.

Supondo que o horário atual seja '2012-03-08 11:00:00', o relatório mostraria (aproximadamente):

Hour  EventCount
----  ----------
23    0
0     0
1     0
2     0
3     0
4     0
5     0
6     0
7     0
8     1
9     3
10    1

Eu vim com uma solução que usa uma tabela que possui um registro para cada hora do dia. Consegui obter os resultados que estava procurando usando uma UNION e alguma lógica de caso complicada na cláusula where, mas esperava que alguém tivesse uma solução mais elegante.

Para o SQL Server 2005+, você pode gerar esses 12 registros com muita facilidade com um loop e um CTE recursivo. Aqui está um exemplo de uma CTE recursiva:

DECLARE @Date DATETIME
SELECT @Date = '20120308 11:00:00'

;WITH Dates AS
(
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,@Date)) [Hour], 
      DATEADD(HOUR,-1,@Date) [Date], 1 Num
    UNION ALL
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,[Date])), 
      DATEADD(HOUR,-1,[Date]), Num+1
    FROM Dates
    WHERE Num <= 11
)
SELECT [Hour], [Date]
FROM Dates

Então você apenas precisa se juntar à sua tabela de eventos.

As tabelas de registro podem ser usadas para coisas assim. Eles podem ser muito eficientes. Crie a tabela de registro abaixo. Criei a tabela de contagem com apenas 24 linhas para o seu exemplo, mas você pode criá-la com quantas desejar para outros fins.

SELECT TOP 24 
        IDENTITY(INT,1,1) AS N
   INTO dbo.Tally
   FROM Master.dbo.SysColumns sc1,
        Master.dbo.SysColumns sc2

--===== Add a Primary Key to maximize performance
  ALTER TABLE dbo.Tally
    ADD CONSTRAINT PK_Tally_N 
        PRIMARY KEY CLUSTERED (N) WITH FILLFACTOR = 100

Supus que sua tabela se chamava dbo.tblEvents, execute a consulta abaixo. Acredito que é isso que você está procurando:

SELECT t.n, count(e.EventTime)
FROM dbo.Tally t
LEFT JOIN dbo.tblEvent e  on t.n = datepart(hh, e.EventTime)
GROUP BY t.n
ORDER BY t.n

Acredito que o crédito vá para os seguintes links, acredito que foi aqui que me deparei com isso:

http://www.sqlservercentral.com/articles/T-SQL/62867/

http://www.sqlservercentral.com/articles/T-SQL/74118/

Primeiro, peço desculpas pelo atraso em minha resposta desde meus últimos comentários.

O assunto surgiu nos comentários de que o uso de uma CTE recursiva (rCTE daqui em diante) é rápido o suficiente devido ao baixo número de linhas. Embora possa parecer assim, nada poderia estar mais longe da verdade.

CONSTRUIR MESA ALTA E FUNÇÃO ALTA

Antes de iniciarmos o teste, precisamos criar uma Tabela Tally física com o Índice de Cluster apropriado e uma Função Tally no estilo Itzik Ben-Gan. Também faremos tudo isso no TempDB para não descartar acidentalmente os presentes de ninguém.

Aqui está o código para criar a Tally Table e minha versão atual de produção do maravilhoso código de Itzik.

--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
--===== Create/Recreate a Physical Tally Table
     IF OBJECT_ID('dbo.Tally','U') IS NOT NULL
        DROP TABLE dbo.Tally
;
     -- Note that the ISNULL makes a NOT NULL column
 SELECT TOP 1000001
        N = ISNULL(ROW_NUMBER() OVER (ORDER BY (SELECT NULL))-1,0)
   INTO dbo.Tally
   FROM      sys.all_columns ac1
  CROSS JOIN sys.all_columns ac2
;
  ALTER TABLE dbo.Tally
    ADD CONSTRAINT PK_Tally PRIMARY KEY CLUSTERED (N)
;
--===== Create/Recreate a Tally Function
     IF OBJECT_ID('dbo.fnTally','IF') IS NOT NULL
        DROP FUNCTION dbo.fnTally
;
GO
 CREATE FUNCTION [dbo].[fnTally]
/**********************************************************************************************************************
 Purpose:
 Return a column of BIGINTs from @ZeroOrOne up to and including @MaxN with a max value of 1 Trillion.

 As a performance note, it takes about 00:02:10 (hh:mm:ss) to generate 1 Billion numbers to a throw-away variable.

 Usage:
--===== Syntax example (Returns BIGINT)
 SELECT t.N
   FROM dbo.fnTally(@ZeroOrOne,@MaxN) t
;

 Notes:
 1. Based on Itzik Ben-Gan's cascading CTE (cCTE) method for creating a "readless" Tally Table source of BIGINTs.
    Refer to the following URLs for how it works and introduction for how it replaces certain loops. 
    http://www.sqlservercentral.com/articles/T-SQL/62867/
    http://sqlmag.com/sql-server/virtual-auxiliary-table-numbers
 2. To start a sequence at 0, @ZeroOrOne must be 0 or NULL. Any other value that's convertable to the BIT data-type
    will cause the sequence to start at 1.
 3. If @ZeroOrOne = 1 and @MaxN = 0, no rows will be returned.
 5. If @MaxN is negative or NULL, a "TOP" error will be returned.
 6. @MaxN must be a positive number from >= the value of @ZeroOrOne up to and including 1 Billion. If a larger
    number is used, the function will silently truncate after 1 Billion. If you actually need a sequence with
    that many values, you should consider using a different tool. ;-)
 7. There will be a substantial reduction in performance if "N" is sorted in descending order.  If a descending 
    sort is required, use code similar to the following. Performance will decrease by about 27% but it's still
    very fast especially compared with just doing a simple descending sort on "N", which is about 20 times slower.
    If @ZeroOrOne is a 0, in this case, remove the "+1" from the code.

    DECLARE @MaxN BIGINT; 
     SELECT @MaxN = 1000;
     SELECT DescendingN = @MaxN-N+1 
       FROM dbo.fnTally(1,@MaxN);

 8. There is no performance penalty for sorting "N" in ascending order because the output is explicity sorted by
    ROW_NUMBER() OVER (ORDER BY (SELECT NULL))

 Revision History:
 Rev 00 - Unknown     - Jeff Moden 
        - Initial creation with error handling for @MaxN.
 Rev 01 - 09 Feb 2013 - Jeff Moden 
        - Modified to start at 0 or 1.
 Rev 02 - 16 May 2013 - Jeff Moden 
        - Removed error handling for @MaxN because of exceptional cases.
 Rev 03 - 22 Apr 2015 - Jeff Moden
        - Modify to handle 1 Trillion rows for experimental purposes.
**********************************************************************************************************************/
        (@ZeroOrOne BIT, @MaxN BIGINT)
RETURNS TABLE WITH SCHEMABINDING AS 
 RETURN WITH
  E1(N) AS (SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL 
            SELECT 1)                                  --10E1 or 10 rows
, E4(N) AS (SELECT 1 FROM E1 a, E1 b, E1 c, E1 d)      --10E4 or 10 Thousand rows
,E12(N) AS (SELECT 1 FROM E4 a, E4 b, E4 c)            --10E12 or 1 Trillion rows                 
            SELECT N = 0 WHERE ISNULL(@ZeroOrOne,0)= 0 --Conditionally start at 0.
             UNION ALL 
            SELECT TOP(@MaxN) N = ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM E12 -- Values from 1 to @MaxN
;
GO

A propósito ... observe que construiu um Tally Table de um milhão e uma linha e adicionou um Índice de Cluster a ele em cerca de um segundo. Experimente ISSO com um rCTE e veja quanto tempo leva! ;-)

CONSTRUA ALGUNS DADOS DE TESTE

Também precisamos de alguns dados de teste. Sim, eu concordo que todas as funções que vamos testar, incluindo o rCTE, são executadas em milissegundos ou menos por apenas 12 linhas, mas essa é a armadilha em que muitas pessoas caem. Falaremos mais sobre essa armadilha mais tarde, mas, por enquanto, vamos simular a chamada de cada função 40.000 vezes, ou seja, quantas vezes certas funções em minha loja são chamadas em um dia de 8 horas. Imagine quantas vezes essas funções podem ser chamadas em um grande negócio de varejo online.

Então, aqui está o código para criar 40.000 linhas com datas aleatórias, cada uma com um número de linha apenas para fins de rastreamento. Não tirei tempo para fazer horas inteiras porque não importa aqui.

--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
--===== Create/Recreate a Test Date table
     IF OBJECT_ID('dbo.TestDate','U') IS NOT NULL
        DROP TABLE dbo.TestDate
;
DECLARE  @StartDate DATETIME
        ,@EndDate   DATETIME
        ,@Rows      INT
;
 SELECT  @StartDate = '2010' --Inclusive
        ,@EndDate   = '2020' --Exclusive
        ,@Rows      = 40000  --Enough to simulate an 8 hour day where I work
;
 SELECT  RowNum       = IDENTITY(INT,1,1)
        ,SomeDateTime = RAND(CHECKSUM(NEWID()))*DATEDIFF(dd,@StartDate,@EndDate)+@StartDate
   INTO dbo.TestDate
   FROM dbo.fnTally(1,@Rows)
;

CONSTRUA ALGUMAS FUNÇÕES PARA FAZER A COISA DAS 12 HORAS

Em seguida, converti o código rCTE em uma função e criei outras 3 funções. Todos eles foram criados como iTVFs de alto desempenho (funções com valor de tabela em linha). Você sempre pode perceber porque os iTVFs nunca têm um BEGIN, como o Scalar ou o mTVFs (funções com valor de tabela de múltiplas instruções).

Aqui está o código para criar essas 4 funções ... Eu os nomeei de acordo com o método que eles usam e não o que eles fazem apenas para facilitar a identificação.

--=====  CREATE THE iTVFs
--===== Do this in a nice, safe place that everyone has
    USE tempdb
;
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.OriginalrCTE','IF') IS NOT NULL
        DROP FUNCTION dbo.OriginalrCTE
;
GO
 CREATE FUNCTION dbo.OriginalrCTE
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
WITH Dates AS
(
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,@Date)) [Hour], 
      DATEADD(HOUR,-1,@Date) [Date], 1 Num
    UNION ALL
    SELECT DATEPART(HOUR,DATEADD(HOUR,-1,[Date])), 
      DATEADD(HOUR,-1,[Date]), Num+1
    FROM Dates
    WHERE Num <= 11
)
SELECT [Hour], [Date]
FROM Dates
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.MicroTally','IF') IS NOT NULL
        DROP FUNCTION dbo.MicroTally
;
GO
 CREATE FUNCTION dbo.MicroTally
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,t.N,@Date))
        ,[DATE] = DATEADD(HOUR,t.N,@Date)
   FROM (VALUES (-1),(-2),(-3),(-4),(-5),(-6),(-7),(-8),(-9),(-10),(-11),(-12))t(N)
;
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.PhysicalTally','IF') IS NOT NULL
        DROP FUNCTION dbo.PhysicalTally
;
GO
 CREATE FUNCTION dbo.PhysicalTally
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
        ,[DATE] = DATEADD(HOUR,-t.N,@Date)
   FROM dbo.Tally t
  WHERE N BETWEEN 1 AND 12
;
GO
-----------------------------------------------------------------------------------------
     IF OBJECT_ID('dbo.TallyFunction','IF') IS NOT NULL
        DROP FUNCTION dbo.TallyFunction
;
GO
 CREATE FUNCTION dbo.TallyFunction
        (@Date DATETIME)
RETURNS TABLE WITH SCHEMABINDING AS
 RETURN
 SELECT  [Hour] = DATEPART(HOUR,DATEADD(HOUR,-t.N,@Date))
        ,[DATE] = DATEADD(HOUR,-t.N,@Date)
   FROM dbo.fnTally(1,12) t
;
GO

CONSTRUA A ARNURA DE TESTE PARA TESTAR AS FUNÇÕES

Por último, mas não menos importante, precisamos de um equipamento de teste. Faço uma verificação de linha de base e testo cada função de maneira idêntica.

Aqui está o código para o equipamento de teste ...

PRINT '--========== Baseline Select =================================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = RowNum
        ,@Date = SomeDateTime
   FROM dbo.TestDate
  CROSS APPLY dbo.fnTally(1,12);
    SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Orginal Recursive CTE ===========================';
DECLARE @Hour INT, @Date DATETIME
;

    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.OriginalrCTE(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT '--========== Dedicated Micro-Tally Table =====================';
DECLARE @Hour INT, @Date DATETIME
;

    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.MicroTally(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Physical Tally Table =============================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.PhysicalTally(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO
PRINT'--========== Tally Function ===================================';
DECLARE @Hour INT, @Date DATETIME
;
    SET STATISTICS TIME,IO ON;
 SELECT  @Hour = fn.[Hour]
        ,@Date = fn.[Date]
   FROM dbo.TestDate td
  CROSS APPLY dbo.TallyFunction(td.SomeDateTime) fn;
    SET STATISTICS TIME,IO OFF;
GO

Uma coisa a observar no equipamento de teste acima é que eu desvio toda a saída para variáveis ​​"descartáveis". Isso é para tentar manter as medições de desempenho o mais puro possível, sem qualquer saída para os resultados de distorção do disco ou da tela.

UMA PALAVRA DE CUIDADO SOBRE ESTATÍSTICAS

Além disso, uma palavra de cautela para os possíveis testadores ... Você NÃO DEVE usar SET STATISTICS ao testar as funções Scalar ou mTVF. Só pode ser usado com segurança em funções do iTVF como as deste teste. Foi comprovado que o SET STATISTICS faz com que as funções SCALAR sejam executadas centenas de vezes mais devagar do que realmente são. Sim, estou tentando inclinar outro moinho de vento, mas isso seria um post completo e não tenho tempo para isso. Eu tenho um artigo no SQLServerCentral.com falando sobre isso, mas não há sentido em postar o link aqui, porque alguém ficará todo deformado com isso.

OS RESULTADOS DO TESTE

Então, aqui estão os resultados do teste quando executo o equipamento de teste no meu laptop i5 com 6 GB de RAM.

--========== Baseline Select =================================
Table 'Worktable'. Scan count 1, logical reads 82309, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 203 ms,  elapsed time = 206 ms.
--========== Orginal Recursive CTE ===========================
Table 'Worktable'. Scan count 40001, logical reads 2960000, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 4258 ms,  elapsed time = 4415 ms.
--========== Dedicated Micro-Tally Table =====================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 234 ms,  elapsed time = 235 ms.
--========== Physical Tally Table =============================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Tally'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 250 ms,  elapsed time = 252 ms.
--========== Tally Function ===================================
Table 'Worktable'. Scan count 1, logical reads 81989, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'TestDate'. Scan count 1, logical reads 105, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 250 ms,  elapsed time = 253 ms.

O "BASELINE SELECT", que seleciona apenas os dados (cada linha criada 12 vezes para simular o mesmo volume de retorno), apareceu aproximadamente 1/5 de segundo. Todo o resto entrou em cerca de um quarto de segundo. Bem, tudo, exceto essa função rCTE sangrenta. Demorou 4 e 1/4 segundos ou 16 vezes mais (1.600% mais lento).

E observe as leituras lógicas (IO da memória) ... O rCTE consumiu 2.960.000 (quase 3 MILHÕES de leituras), enquanto as outras funções consumiram apenas 82.100. Isso significa que o rCTE consumiu mais de 34,3 vezes mais IO de memória do que qualquer outra função.

PENSAMENTOS DE ENCERRAMENTO

Vamos resumir. O método rCTE para fazer essa coisa "pequena" de 12 linhas usou 16 TIMES (1.600%) mais CPU (e duração) e 34.3 TIMES (3.430%) mais IO de memória do que qualquer outra função.

Heh ... eu sei o que você está pensando. "Grande coisa! É apenas uma função."

Sim, concordou, mas quantas outras funções você tem? Quantos outros lugares fora das funções você tem? E você tem algum que trabalhe com mais de apenas 12 linhas cada execução? E, existe alguma chance de alguém que esteja em busca de um método copie esse código rCTE para algo muito maior?

Ok, hora de ser franco. Não faz absolutamente sentido para as pessoas justificarem o código de desempenho comprometido apenas por causa de supostas contagens ou uso de linhas limitadas Exceto quando você compra uma caixa MPP por talvez milhões de dólares (para não mencionar a despesa de reescrever o código para fazê-lo funcionar em uma máquina como essa), você não pode comprar uma máquina que executa seu código 16 vezes mais rápido (os SSDs vencidos também não ... tudo isso estava na memória de alta velocidade quando testamos). O desempenho está no código. Bom desempenho está em bom código.

Você pode imaginar se todo o seu código foi executado "apenas" 16 vezes mais rápido?

Nunca justifique código ruim ou com problemas de desempenho em contas de linha baixas ou mesmo baixo uso. Se o fizer, pode ser necessário emprestar um dos moinhos de vento nos quais fui acusado de inclinar para manter suas CPUs e discos suficientemente frios. ;-)

UMA PALAVRA NA PALAVRA "TOTALMENTE"

Sim, eu concordo. Semanticamente falando, a Tabela Tally contém números, não "contagens". No meu artigo original sobre o assunto (não era o artigo original sobre a técnica, mas foi o meu primeiro), chamei de "Tally" não por causa do que ele contém, mas por causa do que faz ... costumava "contar" em vez de repetir e "registrar" alguma coisa é "contar" alguma coisa. ;-) Chame como quiser ... Tabela de Números, Tabela de Tally, Tabela de Sequência, o que for. Eu não ligo Para mim, "Tally" tem mais significado e, sendo um bom DBA preguiçoso, contém apenas 5 letras (2 são idênticas) em vez de 7 e é mais fácil dizer para a maioria das pessoas. Também é "singular", que segue minha convenção de nomenclatura para tabelas. ;-) Isto' s também como o artigo que continha uma página de um livro dos anos 60 o chamou. Eu sempre me referirei a ela como uma "Tabela de Registro" e você ainda saberá o que eu ou outra pessoa queremos dizer. Também evito a notação húngara como a praga, mas chamei a função "fnTally" para que eu pudesse dizer "Bem, se você usasse a efetiva função Tally que eu mostrei, você não teria um problema de desempenho" sem que ela realmente fosse uma Violação de RH. ;-) sem que seja realmente uma violação de RH. ;-) sem que seja realmente uma violação de RH. ;-)

O que mais me preocupa é que as pessoas aprendam a usá-lo adequadamente, em vez de recorrer a coisas como rCTEs com problemas de desempenho e outras formas de RBAR oculto.

Você precisará dos RIGHT JOINseus dados com uma consulta retornando um registro a cada hora que precisar.

Veja isso em algumas maneiras de obter números de linhas que você pode subtrair em horas do horário atual.

No Oracle, uma consulta hierárquica no dual irá gerar linhas:

SELECT to_char(sysdate-level/24,'HH24') FROM dual CONNECT BY Level <=24;