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