我们开始设计数据集市/仓库的构建块，我们需要能够支持所有时区（我们的客户来自世界各地）。从在线（和书籍）阅读讨论来看，一个常见的解决方案似乎是在事实表中具有单独的日期和时间维度以及时间戳。
但是，我很难回答的问题是，考虑到我的动态时区要求，日期和时间维度实际上对我有什么好处？时间维度更有意义，但我很难处理日期维度。日期维度的一般设计方法通常包括日期名称、星期几、月份名称等属性。我遇到的问题是 UTC 时间 2013 年 12 月 31 日星期二晚上 11:00 是星期三, 2014 年 1 月 1 日，在 UTC+2 之后的所有时区。
因此，如果我必须对每个查询（和报告）进行所有这些时区转换，那么拥有和存储这些我可能永远不会使用的属性有什么意义（似乎）？有些人建议为每个时区设置事实行，但这对我来说似乎很荒谬。我们需要能够每月存储数百万条记录。
其他人建议有一个时区桥接表，虽然有一定的意义，但它似乎也需要额外的复杂性和额外的连接来完成我的客户端应用程序和报告应该能够从某个日期轻松计算出来的事情（报告将主要基于 Web那里有无数的库可以帮助转换、显示和格式化日期）。
我唯一能想到的是按日期和小时分组的简便性和可能的性能，但是按日期部分分组的做法有多糟糕（我们正在使用 MS SQL，但我们将查询数百万行）或者我们应该考虑只是非常简单的日期和时间维度，大多数情况下不超过小时、日、月和年的数字，因为大多数文字（例如星期一）在时区发挥作用时意义不大？