Разница в производительности хранилища данных денормализует время - PullRequest
0 голосов
/ 04 марта 2011

В книгах я читал, что это реальное повышение производительности, если вы разделите время на отдельный столбец.например, день, месяц, год и т. д. ...

  1. Есть ли у баз данных уже какой-то умный подход для обработки указателей по столбцам времени, так что разделение времени и добавление миллионов вариантов индексаустарел?

  2. Есть ли разница в производительности?

Возможным запросом будут продажи в понедельник утром с 13:00 до 14:00.«часы.

Ответы [ 4 ]

2 голосов
/ 04 марта 2011
0 голосов
/ 04 марта 2011

Во многих схемах типа «звезда» полезно иметь измерение времени.В этой таблице измерений может быть полезно четко указать день недели, месяц и т. Д.Многие из этих атрибутов могут быть доступны с помощью встроенных функций на вашем диалекте SQL.При использовании функций требуется меньше дискового ввода-вывода, чем при материализации этих данных.Но это делает искусство составления отчетов по заданным временным интервалам намного проще, если функции календаря просто выглядят как данные.

Где это может быть действительно полезно, так это то, что у вашего предприятия есть своеобразный «канонизатор компании», где даты могут принадлежатьк единицам, называемым «фискальными кварталами», которые не легко отображаются на день-месяц-год.Если вы поместите все причуды календаря в одну программу, которая генерирует таблицу измерения времени, она может сделать весь код вашего склада намного более чистым.

Как и в случае с любой таблицей измерений, очень важно установитьгранулярность правильная.Если вам нужна только одна строка в день, вы можете хранить даты за десять лет с более чем 3650 строками - крошечная таблица по современным стандартам.В некоторых случаях «сдвиг» (8-часовой период) оказывается правильной гранулярностью.Это зависит от использования данных.

Независимо от того, по какому пути вы идете, будьте готовы к тому, что ваши данные претерпят «метаморфозу» при настройке хранилища, и будьте готовы к «пробному», когдастолкнулся с неожиданными требованиями.

0 голосов
/ 04 марта 2011

Функциональный индекс является одним из возможных вариантов. Индексированное представление - другое.

Простое создание нового атрибута не повышает производительность. Любая разница в производительности связана с базовыми изменениями в способе хранения и индексации данных. Поэтому вводить в заблуждение и вводить в заблуждение столбцы даты и времени очень упрощает и очень упрощает. Тем не менее, создание отдельного временного столбца может быть хорошей идеей по другим причинам, например: для ясности, упрощения логики запросов или наилучшего использования типов даты / времени СУБД и других функций.

0 голосов
/ 04 марта 2011

Конкретный сценарий, который вы наметили (13: 00-14: 00 каждый понедельник), не может должным образом обслуживаться обычными индексами для данных даты и времени.

Потребуется много разбить данные о времени и дате на день недели + часть времени, чтобы получить эту информацию. Для этого сценария разбиение его на столбец для дня недели и другого для времени дня (часа) будет работать намного лучше и может быть проиндексирован отдельно или в виде составного (для обоих).

Производительность сильно отличается - вместо просмотра 1/168 данных (теоретического среднего) или более реалистично около 1/50 данных (рабочих часов), используя индексы день недели + время дня в противном случае запрос должен был бы выполнить 2 преобразования (чтобы получить компоненты дня недели + время дня), а затем выполнить это через фильтр.

...