2
数据仓库设计,用于针对多个时区的数据进行报告
我们正在尝试优化数据仓库设计,以支持针对许多时区的数据进行报告。例如,我们可能有一个关于一个月活动的报告(数百万行),该报告需要显示按一天中的小时分组的活动。当然,一天中的那个小时必须是给定时区的“本地”小时。 当我们仅支持UTC和一个本地时间时,我们的设计效果很好。事实表上的UTC和本地时间的日期和时间维度的标准设计。但是,如果我们必须支持100多个时区的报告,则该方法似乎无法扩展。 我们的事实表将变得非常广泛。另外,我们还必须解决SQL中的语法问题,即指定在报告的任何给定运行中使用哪个日期和时间ID进行分组。也许是一个非常大的CASE语句? 我已经看到了一些建议,可以按您覆盖的UTC时间范围获取所有数据,然后将其返回到表示层以转换为本地并在那里进行汇总,但是使用SSRS进行的有限测试表明这将非常慢。 我也参考了一些有关该主题的书籍,它们似乎都说只有UTC并可以进行转换,或者只有UTC和一个本地语言。将不胜感激任何想法和建议。 注意:此问题类似于:在数据集市/仓库中处理时区,但是我无法对此问题发表评论,因此感到这是值得的。 更新:在 Aaron进行了一些重大更新并发布了示例代码和图表之后,我选择了Aaron的答案。我先前对他的答案的评论不再有意义,因为它们涉及答案的原始编辑。如果有必要,我会尝试再次更新此内容