我们开始设计数据集市/仓库的构建块，我们需要能够支持所有时区（我们的客户来自世界各地） . 从在线阅读讨论（和书籍），一个常见的解决方案似乎是在事实表中有一个单独的日期和时间维度以及时间戳 .
但是，我很难回答的问题是，考虑到我的动态时区要求，日期和时间维度对我的影响有多大？时间维度更有意义但我在日期维度上遇到了困难 . 日期维度的一般设计方法通常包括诸如日期名称，星期几，月份名称等属性 . 我所遇到的问题是2013年12月31日星期二晚上11点在UTC是星期三，2014年1月1日，在UTC 2之后的所有时区 .
因此，如果我必须对每个查询（和报告）进行所有这些时区转换，那么拥有和存储这些我可能永远不会使用的属性（似乎）是什么意思？有些人建议为每个时区都设置事实行，但这对我来说似乎很荒谬 . 我们需要每月存储数百万条记录 .
其他人建议有一个时区桥接表虽然有一定意义，但它似乎还有额外的复杂性和额外的连接来完成我的客户端应用程序和报告应该能够从日期中轻松搞定的内容（报告将主要基于Web哪里有无数的库来帮助转换，显示和格式化日期） .
我唯一能想到的是按日期和小时分组的简易性和可能性，但是按日期部分分组是多么糟糕（我们使用的是MS SQL，但我们将查询数百万行）或者我们应该考虑只是非常简单的日期和时间维度，大多数情况下只有小时，日，月和年数字，因为大多数文字如星期一在时区发挥作用时并不意味着什么？
1 回答
要做出此类决定，首先需要确定要对数据仓库中的数据回答哪些问题 . 事实是否与客户的当地时间，某个中心位置的当地时间（例如您的公司总部）有关，或者可以与任意时区的日期相关联，比如UTC？您是否有关于客户时区的信息？
当来自不同时区的两个人查询您的数据仓库时，他们应该看到完全相同的结果，还是应该将事实报告为落在相应时区的日期？
例如，如果您正在报道观看有线电视的人，则事实自然属于当地时区，因为客户位于有线电视前端附近 . 如果您报告通过Internet观看内容的客户，您可能对服务器的负载感兴趣，那么在您的服务器所在的时区报告是有意义的 .