在數據集市/倉庫中處理時區

Question

我們開始設計數據集市/倉庫的構建模塊，我們需要能夠支持所有時區（我們的客戶來自世界各地）。從閱讀在線討論（和書籍），一個常見的解決方案似乎是在事實表中具有單獨的日期和時間維度以及時間戳。

但是，我有難以回答的問題是日期和時間維度實際上對我考慮動態時區要求有什麼好處？時間維度更有意義，但我在日期維度上遇到困難。日期維度的一般設計方法通常包括諸如日期名稱，星期幾，月份名稱等屬性。我所遇到的問題是，2013年12月31日星期二晚上11:00以UTC表示的問題是星期三，2014年1月1日，在UTC + 2之後的所有時區中。

因此，如果我將不得不在每個查詢（和報告）上執行所有這些時區轉換，那麼擁有和存儲這些屬性的重點是什麼，我可能永遠不會使用（看起來像）？有些人建議每個時區都有事實排，但這對我來說似乎很荒謬。我們需要能夠每月存儲數百萬條記錄。

其他人建議有一個時區橋表，雖然有一定意義，但它似乎是額外的複雜性和額外的連接來完成我的客戶端應用程序和報表應該很容易從日期中找出的東西（報表將是主要基於網絡，其中有無數的圖書館來幫助轉換，顯示和格式化日期）。

我能想到的唯一的事情是易用性和可能通過日期和時間，但如何在實踐中不好的是由日期部分組性能分組（我們使用的是MS SQL，但我們將是查詢數百萬行），還是應該考慮非常簡單的日期和時間維度，其中大部分時間，日期，月份和年份的數據不多，因爲大多數文字（如星期一）在時區發揮作用時沒有多大意義。

Answer 1

爲了做出這樣的決定，您首先需要確定您想要用數據倉庫中的數據回答哪些問題。是事實與客戶當地時間，某個中心位置的本地時間（例如您的公司總部）有意義的關聯，還是可以與任意時區中的日期相關聯，例如UTC？你甚至有關於客戶的時區的信息嗎？

當兩個來自不同時區的人查詢您的數據倉庫時，他們是否應該看到完全相同的結果，或者應該將事實報告爲落在相應時區的日期？

例如，如果您正在報告觀看有線電視的人，事實自然會落入當地時區，因爲客戶位於有線電視前端附近。如果您要通過互聯網向客戶收看內容進行報告，您可能會對服務器的負載感興趣，那麼在服務器所在的時區進行報告會很有意義。