1
我在讀一本關於數據倉庫的書。它告訴如果我有日期時間數據，我應該將它作爲單獨的列存儲：年份，月份，日期和原始日期時間（以毫秒爲單位）。這是需要聚合的目的（另請參閱更新部分） - 按日期，月份等聚合但如果我需要聚合不同的時區？是的，可以在用戶界面上顯示UTC +時區，但如果企業希望在「轉移」的日期時間內看到彙總，那麼當天不會在00：00 + 07時開始彙總？在OLAP計算過程中用什麼技術處理不同的時區？
注意
它可以計算每個時區每次聚集（年，月，日），但它需要太多的計算（據我所知）。
也許有更好的辦法？或者每個時區的每個計算都是一個常見的解決方案？
更新
關於聚集。通過aggreagetion，我的意思是說，有一個進程按計劃運行（它首次運行所有數據，然後按計劃僅運行新進程）。因此，該過程在「看到」新數據時會計算所有列的聚合。例如，假設數據是客戶訂單，它具有成本，用戶標識和日期。因此，處理具有1個cutomer順序的抓取行並將這些信息「添加」到幾個OLAP立方體單元中：日，月和年。假設客戶在22.06.2015上訂購$1。此訂單數據（通常爲成本）在以下OLAP單元上「添加」：22一天，06月和2015。我不是合格的OLAP設計師，單元格可能不同（例如，它可以添加到22.06而不是22），但是想法是爲了查詢優化目的將數據放入單獨的單元格中，例如，從一個多維數據集單元22.06.2015中選擇成本總和，而不是在22.06.2015上的所有訂單的運行計算速度要快得多。但是在這種情況下，UTC的設計日開始，如果我需要從不同的時區開始呢？採用這種方法，數據彙總增加了24倍。在UTC :(
存儲日期，並顯示在與偏移是常見的做法，但不是在OLAP設計時，我需要預先計算UI。
請在downvoting時發表評論。 – Cherry
我想你只是不要在數據庫中這樣做，而是在你用來生成報告形式的結果的工具中，或者你想/需要顯示數據。如果時區對您很重要，那麼請使用一個字段來存儲時區。 –
再次：使用另一個字段來存儲該日期的相關時區。當客戶端使用數據時，在**那一刻**您將在時區上運行。但是，嚴肅地說，我看不出公司在一個時區或另一個時區賺得多少錢，並將其用作報告相關數據的一部分。我發現真正有用的是我可以用來做出面向業務決策的適當時間。 –