DateTime как часть PK в FACT Table для складов - PullRequest
Новая
       11

DateTime как часть PK в FACT Table для складов

1 голос
/ 27 мая 2011

Я знаю, что в общем случае не рекомендуется использовать столбец DateTime в качестве вашего PK, однако для моей ситуации я считаю, что это более целесообразно, чем суррогатный ключ в таблице фактов.

Причины ...

  1. Данные, вставленные в таблицу фактов, всегда последовательны. т.е. я бы никогда не вставил значение даты и времени, которое старше, чем последнее значение, уже в таблице фактов.
  2. Поле даты и времени - не единственный столбец PK (составной PK), PK, конечно, сам по себе и суррогатный ключ измерения FK.
  3. То, как я запрашиваю данные, почти всегда основано на времени.
  4. Суррогатный ключ в таблице фактов ничего не скажет о строке. Каждая строка уже уникальна, и чтобы найти этот конкретный факт, я бы всегда сначала фильтровал по дате и значениям в измерениях.
  5. Нет отдельной таблицы измерений даты и времени. Нет необходимости сейчас или в обозримом будущем иметь именованные моменты времени и т. Д.

Дополнительные замечания - время будет в UTC и с использованием SQL 2008 R2.

То, что я спрашиваю, это дать ситуацию - каковы недостатки этого? Буду ли я сталкиваться с непредвиденными проблемами? Является ли это на самом деле хорошей вещью при последующих запросах этих данных?

Хотелось бы знать точки зрения людей в поле DateTime как первый столбец составного PK.

Ответы [ 2 ]

3 голосов
/ 27 мая 2011

Это почти существенная особенность любого хранилища данных, что дата / время являются компонентом ключа в большинстве таблиц.В этом нет ничего «неправильного».

Суррогатный ключ обычно не должен быть ключом only таблицы, поэтому, возможно, ваш вопрос действительно "Должен ли я создать суррогатный ключ на моемстол, а?Мое предложение состоит в том, что, если у вас нет причины создавать суррогатный ключ, не делайте этого.Время создавать суррогат - это когда вам нужно.

0 голосов
/ 27 мая 2011

Большинство таблиц фактов имеют составные ключи, и часто в них входят дата-время или часто DateKey, TimeKey. На самом деле, довольно часто.

dimDate и dimTime просто используются, чтобы избежать "забавных" функций даты и времени в предложении WHERE запроса. Например 

-- sales on
-- weekends for previous 28 weeks
-- 
select sum(f.SaleAmount)
from factSale as f
join dimDate  as d on d.DateKey = f.DateKey 
where d.IsWeekend = 'yes'
  and d.WeeksAgo between 1 and 28 ;

Так что здесь у меня могут быть индексы на IsWeekend и WeeksAgo (тоже DateKey). Если бы они были заменены функциями даты и времени, это вызвало бы построчную обработку.

...