Обробка часових поясів у марті / складі даних

Ми починаємо проектувати будівельні блоки марта / складу даних, і нам потрібно мати можливість підтримувати всі часові пояси (наші клієнти з усього світу). Починаючи з читання дискусій в Інтернеті (і в книгах), загальним рішенням, як видається, є окремий вимір дати та часу, а також часові позначки в таблицях фактів.

Однак питання, на яке я важко відповідаю, полягає в тому, що корисного для нас дійсно мають розміри дати та часу, враховуючи мої вимоги до динамічного часового поясу? Часовий вимір має трохи більше сенсу, але мені важко з виміром дати. Загальний підхід до проектування розміру дати зазвичай включає такі властивості, як назва дня, день тижня, назва місяця тощо. Проблема, з якою я маю те, що в 23:00 у вівторок, 31 грудня 2013 року в UTC, є середа , 1 січня 2014 року у всіх часових поясах, що перебувають після UTC + 2.

Отже, якщо мені доведеться робити всі ці перетворення часового поясу для кожного запиту (та звіту), то який сенс мати та зберігати ці властивості, які я, мабуть, ніколи не буду використовувати (здається)? Деякі люди пропонують мати рядки для кожного часового поясу, але це здається мені смішним. Нам потрібно мати можливість зберігати мільйони записів щомісяця.

Інші пропонують створити таблицю перемикання часового поясу, яка хоч і має певний сенс, але це також здається додатковою складністю та додатковими приєднаннями, щоб досягти чогось, що мої клієнтські програми та звіти повинні бути легко зрозуміти з дати (звіт буде в основному веб-базією) де є безліч бібліотек, які допомагають перетворювати, відображати та форматувати дати).

Єдине, про що я можу придумати, - це легкість та можливо виконання групувань за датою та годиною, але як погана практика - групувати за датою (ми використовуємо MS SQL, але ми будемо запитувати мільйони рядків) або чи варто нам врахувати просто надзвичайно прості розміри дати та часу з числом не більше години, дня, місяця та року здебільшого, оскільки більшість літералістів, таких як понеділок, не означатиме багато часу, коли грають часові пояси?

По-перше ...

Поділ Datime/Timeна Dateвимір і Timeвимір - це безумовно шлях.

Для управління кількома часовими поясами потрібно дублювати DateKeyі TimeKeyтак, щоб у вас було наступне:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Ти кажеш...

Проблема, з якою у мене виникає, полягає в тому, що 23:00 у вівторок, 31 грудня 2013 року в UTC, є середа, 1 січня 2014 року у всіх часових поясах, що перебувають після UTC + 2.

Маючи чотири стовпці, які я перераховував вище, ви зможете приєднати таблицю фактів до виміру дати та / або часу за допомогою псевдонімів таблиці (у термінології Кімбола ці псевдонімірні таблиці розмірів відомі як "Розміри рольової гри"), так у вас буде щось таке:

/*
    Assumes the following:
        - [DateLongName] has the format of this example "Tuesday, December 31, 2013"
        - [TimeShortName] has the format of this example "11:00 PM"
        - Both [DateLongName] & [TimeShortName] are strings
*/
select
    -- Returns a string matching this example  "11:00 PM Tuesday, December 31, 2013"
    localTime.TimeShortName + ' ' + localDate.DateLongName
    ,utcTime.TimeShortName + ' ' + utcDate.DateLongName
    ,f.*
from
    FactTableName  AS f

    -- Local Date and Local Time joins          
    inner join dbo.Date  AS localDate
        on localDate.DateKey = f.LocalDateKey

    inner join dbo.Time  AS localTime
        on localTime.TimeKey = f.LocalTimeKey 

    -- Utc Date and Utc Time joins    
    inner join dbo.Date  AS utcDate
        on utcDate.DateKey = f.UtcDateKey

    inner join dbo.Time  AS utcTime
        on utcTime.TimeKey = f.UtcTimeKey 

На завершення ...

Оскільки ви створюєте март даних, а не базу даних OLTP, генерація локальних та Utc часів повинна виконуватися у вашому ETL , а не в будь-яких клієнтських програмах з наступних причин (крім локалізації часу UTC до звіт читача):

• Отримавши обчислення в будь-яких запитах, накладається на них додаткове навантаження на ефективність, помножене на кількість разів, коли вам потрібно буде виконати зазначений запит для будь-яких звітів (це має значення при читанні мільйонів рядків)
• Додатковий тягар забезпечення правильного ведення розрахунків у кожному запиті (особливо якщо враховувати літній час)
• Не допускати сканування діапазону будь-яких індексів, до яких стовпець є частиною, оскільки ви будете виконувати обчислення на стовпці, яке змушує запити виконувати сканування індексу замість шукань (які, як правило, дорожчі, оскільки кожна сторінка даних потрібна для читання); це відомо як НЕ - sargable .
  • Редагувати завдяки коментарям: Це застосовується, якщо ви пересунете конверсію вниз у фактичний запит .
• Використовуючи концепцію доступності додаткових дат та часу UTC, ніщо не заважає вам прийняти та розширити цю концепцію і поширити її, зателефонувавши до цього StandardisedDateKey, або CorporateHQDateKey, замість того, щоб таблицю дат UTC, ви стандартизуєте, грунтуючись на іншому діловому узгодженому стандарті
• Наявність двох окремих типів стовпців (Local та UTC) дозволяє порівнювати побічні географічні відстані. Подумайте -> хтось в Австралії вводить запис, який позначається часом як Local, так і UTC, хтось у Нью-Йорку читає звіт із місцевою (Австралією) датою та часом та нью-йоркським представленням дати та часу UTC, тим самим бачачи, що щось їхній австралійський колега в середині дня (за австралійським часом) траплявся посеред ночі (Нью-Йоркський час). Таке порівняння часу є незамінним у багатонаціональному бізнесі.

Я вибачаюсь заздалегідь за стислість цієї відповіді і планую детально розробитись, коли я не на роботі.

Напевно, переваги мають таблиці дати та часу, оскільки вони дозволяють легко агрегувати ваші дані. У багатьох випадках це найпростіший спосіб сортувати за місяцем або робочими днями речі такого характеру. Однак це не обов'язково замінює корисність мітки часу. У вашому конкретному випадку часова позначка UTC. Після того, як ви позначите часову позначку, все, що вам потрібно зробити, це змінити місцевий час у звіті чи презентаційному шарі. Щоб уникнути сканування діапазону, переконайтеся, що ви також перетворюєте діапазон запитів на час UTC.

Якщо будь-які інші запитання чи коментарі, сміливо запитайте.