处理数据集市/仓库中的时区

Question

我们开始设计数据集市/仓库的构建块，我们需要能够支持所有时区（我们的客户来自世界各地）。从在线（和书籍）阅读讨论来看，一个常见的解决方案似乎是在事实表中具有单独的日期和时间维度以及时间戳。

但是，我很难回答的问题是，考虑到我的动态时区要求，日期和时间维度实际上对我有什么好处？时间维度更有意义，但我很难处理日期维度。日期维度的一般设计方法通常包括日期名称、星期几、月份名称等属性。我遇到的问题是 UTC 时间 2013 年 12 月 31 日星期二晚上 11:00 是星期三, 2014 年 1 月 1 日，在 UTC+2 之后的所有时区。

因此，如果我必须对每个查询（和报告）进行所有这些时区转换，那么拥有和存储这些我可能永远不会使用的属性有什么意义（似乎）？有些人建议为每个时区设置事实行，但这对我来说似乎很荒谬。我们需要能够每月存储数百万条记录。

其他人建议有一个时区桥接表，虽然这很有意义，但它似乎也需要额外的复杂性和额外的连接来完成我的客户端应用程序和报告应该能够从某个日期轻松计算出来的事情（报告将主要是基于网络的，其中有无数的图书馆可以帮助转换、显示和格式化日期）。

我唯一能想到的是按日期和小时分组的简便性和可能的​​性能，但是按日期部分分组的做法有多糟糕（我们使用的是 MS SQL，但我们会查询数百万行）还是我们应该只考虑非常简单的日期和时间维度，大部分时间不超过小时、日、月和年的数字，因为大多数文字（例如星期一）在时区进入时意义不大玩吗？

Answer 1

要做出这样的决定，您首先需要确定您希望使用数据仓库中的数据回答哪些问题。事实是否与客户的当地时间、某个中心位置的当地时间（例如您的公司总部）有意义地相关联，或者可以与任意时区中的日期相关联，例如 UTC？你甚至有关于客户时区的信息吗？

当来自不同时区的两个人查询您的数据仓库时，他们应该看到完全相同的结果，还是应该将事实报告为对应时区的日期？

例如，如果您要报道观看有线电视的人，则事实自然会落入当地时区，因为客户位于有线电视头端附近。如果您正在报告通过 Internet 观看内容的客户，您可能对服务器的负载感兴趣，那么在您的服务器所在的时区进行报告将是有意义的。