Tenho uma tabela que armazena os resultados das consultas que são executadas pelo menos uma vez ao dia. Há uma bit
coluna que representa se a linha é da execução mais recente de uma consulta específica com um conjunto específico de argumentos. (Sim, é uma dependência funcional, mas uma desnormalização necessária para o desempenho, já que a maioria das consultas nesta tabela está interessada apenas no resultado mais recente.)
Como essa bit
coluna é quase sempre um valor falso, estou procurando a melhor maneira de ajustar as consultas retornando apenas os valores verdadeiros. O particionamento não é uma opção (Edição Standard). Parece que tornar a coluna SPARSE seria uma solução interessante, mas acredito que isso exigiria que eu alterasse a coluna para anulável e usasse NULL em vez de 0 para valores falsos. Parece um pouco kludgy.
Existe uma opção semelhante ao SPARSE que otimizaria o espaço/desempenho para uma coluna de bit não nula com a maioria (bem mais de 99%) de valores falsos?
O artigo de Pinal Dave indica que os valores zero e nulo são otimizados, mas isso não parece certo para mim, pois são valores diferentes - a menos que o MSSQL esteja usando o mesmo mecanismo para colunas não nulas para indicar o valor padrão. Isso seria ótimo se fosse verdade, mas o BOL não menciona isso.
Um índice filtrado (
WHERE IsMostRecentRun = 1
) parece uma ideia melhor para mim do que usar esparso. Se você puder fazer com quefalse
seja representado pornull
, poderá fazer as duas coisas, mas, embora isso economize algum espaço na tabela base, suspeito que o maior ganho seria no desempenho da consulta do índice filtrado - contanto como está cobrindo. Se você precisar cobrir muitas colunas e/ou também filtrar ou unir outras colunas, poderá encontrar um equilíbrio entre as melhorias obtidas com a busca ou varredura de intervalo no índice filtrado e os custos de coisas como pesquisas para chegar ao resto das colunas.Dito isso, parece suspeito que você precisaria de uma coluna adicional para servir como sinalizador para isso. Essa informação não é redundante? Não pode ser determinado por outros dados? Nesse caso, eu me concentraria no ajuste do índice para otimizar o uso das colunas existentes, em vez de armazenar e manter dados redundantes.
(Também não acho que Pinal esteja correto.)