Мы только начинаем проектировать новое хранилище данных и пытаемся спроектировать, как будут работать наши измерения даты и времени. Нам нужно иметь возможность поддерживать несколько часовых поясов (вероятно, по крайней мере GMT, IST, PST и EST). Сначала мы думали, что у нас будет одно общее объединенное измерение даты и времени, вплоть до, возможно, 15-минутной детализации, таким образом, у нас будет один ключ в наших таблицах фактов, и все разные данные даты и времени для всех поддерживаемых часовых поясов находятся в одной таблице измерений. (т. е. ключ даты, дата по Гринвичу, время по Гринвичу, дата по Гринвичу, время по Гринвичу и т. д.)
Кимбалл предлагает иметь отдельное измерение дня из измерения времени дня, чтобы таблица не становилась слишком большой (набор инструментов хранилища данных, стр. 240), но это звучит хорошо, но это означает, что у нас есть два ключа в наших таблицах фактов для каждого часового пояса. нам нужно поддержать (один для даты и один для времени суток).
Поскольку я очень неопытен в этой области, я надеюсь, что кто-то там знает компромиссы между двумя подходами, то есть производительность и управление всеми различными ключами часового пояса. Возможно, есть и другие подходы, я видел, как некоторые люди говорили о наличии отдельной строки в таблице фактов для часового пояса, но это кажется проблемой, если ваши таблицы фактов состоят из миллионов строк, то вам нужно увеличить их в четыре раза, чтобы добавить часовые пояса. ,
Если мы сделаем 15-минутное зерно, у нас будет 131 400 (24 * 15 * 365) строк в год в нашей таблице измерений даты и времени, которая не звучит слишком ужасно для производительности, но мы не будем знать наверняка, пока мы не протестируем некоторые прототип запросов. Другая проблема, связанная с наличием отдельных ключей часовых поясов в таблице фактов, заключается в том, что запрос должен присоединить таблицу измерений к другому столбцу на основе желаемого часового пояса, возможно, это то, что SSAS позаботится о вас, я не уверен ,
спасибо за любые мысли, -Matt