#sql #database-design #data-warehouse #clustered-index
#sql #база данных-дизайн #хранилище данных #кластеризованный индекс
Вопрос:
Я знаю, что, как правило, не очень хорошая идея использовать столбец DateTime в качестве вашего PK, однако для моей ситуации я считаю, что это имеет больше смысла, чем иметь суррогатный ключ в таблице фактов.
Причины таковы…
- Данные, вставляемые в таблицу фактов, всегда являются последовательными. т. Е. я бы никогда не вставлял значение даты и времени, которое старше последнего значения, уже имеющегося в таблице фактов.
- Поле даты и времени не является единственным столбцом PK (составной PK), PK, конечно, является самим собой и суррогатным ключом измерения FK.
- Способ, которым я запрашиваю данные, почти всегда основан на времени.
- Суррогатный ключ в таблице фактов ничего не сказал бы мне о строке. Каждая строка уже уникальна, и чтобы найти этот конкретный факт, я бы всегда сначала фильтровал дату и время и значения в измерениях.
- Отдельной таблицы измерений datetime не существует. Ни сейчас, ни в обозримом будущем не требуется указывать именованные моменты времени и т.д.
Дополнительные примечания — время будет указано в UTC и с использованием SQL 2008 R2.
Что я спрашиваю, так это то, что вы описываете ситуацию — каковы недостатки в этом? Столкнусь ли я с непредвиденными проблемами? Действительно ли это полезно делать при последующем запросе этих данных?
Хотелось бы знать точки зрения пользователей на поле DateTime в качестве первого столбца составного PK.
Ответ №1:
Практически неотъемлемая особенность любого хранилища данных заключается в том, что дата / время является компонентом ключа в большинстве таблиц. В этом нет ничего «неправильного».
Суррогатный ключ обычно не должен быть единственным ключом таблицы, поэтому, возможно, ваш вопрос действительно «Должен ли я создать суррогатный ключ и в моей таблице?». Мое предложение заключается в том, что если у вас нет причины создавать суррогатный ключ, то не делайте этого. Время для создания суррогата наступает, когда вы обнаружите, что оно вам нужно.
Комментарии:
1. Я тут немного поразмыслил — в частности, о разделении страниц. Я видел ситуацию, когда данные могут не входить в таблицу фактов последовательно, т. Е. некоторые старые данные могут входить в факт. Если PK сначала был кластеризован по дате, то страницам может потребоваться реорганизация. Поэтому я думаю, что я сохраню PK в качестве даты и времени, а FK — в соответствии с размерами, но не буду делать его кластеризованным. Тогда у меня будет суррогатный ключ (идентификатор) в качестве индекса clusterd, хотя я, вероятно, никогда не использую его ни в одном из своих запросов. Тогда это должно дать преимущество более быстрой вставки, а запрос должен выполняться с одинаковой скоростью.
2. Определение ключей — это вопрос логического проектирования. Определение кластеризации — это вопрос физического проектирования. Не путайте эти два. И кластеризация исторических данных вокруг любого идентификатора объектов, о которых вы ведете историю, может фактически ускорить чтение на порядки вместо просто «равной скорости» !
Ответ №2:
Большинство таблиц фактов имеют составные ключи и дату-время или часто 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 тоже). Если бы они были заменены функциями даты и времени, это вызвало бы построчную обработку.