我正在构建一个数据仓库。每个事实都有它的timestamp。我需要按天、月、季度但也按小时创建报告。查看示例，我发现日期倾向于保存在维度表中。
（来源：etl-tools.info）
但我认为，时间没有意义。维度表会不断增长。另一方面，使用日期维度表 JOIN 比在 SQL 中使用日期/时间函数更有效。
您有什么意见/解决方案？
（我正在使用 Infobright）
【问题讨论】：
Kimball 建议使用单独的时间和日期维度：
design-tip-51-latest-thinking-on-time-dimension-tables
在之前的 Toolkit 书籍中，我们有 推荐建造这样一个维度 带有分钟或秒组件 时间作为从午夜的偏移量 每一天，但我们已经开始意识到 最终用户 申请变得太难了， 尤其是在尝试计算时间时 跨越。此外，与日历日不同 维度，很少 的描述性属性 特定分钟或秒内 天。如果企业有好 时间片的定义属性 一天之内，例如班次名称，或 广告时段，额外的 时间维度可以添加到 这个维度所在的设计 定义为分钟数（或 甚至几秒钟）午夜过后。因此这 时间维度要么有 1440 条记录，如果谷物是分钟 或 86,400 条记录，如果谷物是 秒。
【讨论】：
between '2010-03-22 23:30' and '2010-03-23 11:15' 这样的过滤时间窗口真的不好操作两个连接表。
我的猜测是，这取决于您的报告要求。 如果你需要类似的东西
WHERE "Hour" = 10
意思是每天 10:00:00 到 10:59:59 之间，那么我会使用时间维度，因为它比时间维度要快
WHERE date_part('hour', TimeStamp) = 10
因为 date_part() 函数将针对每一行进行评估。 您仍应将 TimeStamp 保留在事实表中，以便在天数范围内进行聚合，例如：
WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15'
使用维度字段时会变得很尴尬。
通常，时间维度的分辨率为分钟，因此为 1440 行。
【讨论】：
DateTime 维度会更大（365*10*24 = 每小时 87,600 条记录）但仍然不是很大，并且会使时区计算更加容易。
Dates 表和一个Times 表。但是，当您确实有日期时间值时，为什么要使用两个键和双连接而不是单个四字节 FK 到 DateTimes 表？对我来说效果很好，但有些人似乎对它过敏，原因不明。
时间应该是数据仓库的一个维度，因为您经常需要对它进行汇总。您可以使用snowflake-Schema 来减少开销。总的来说，正如我在评论中指出的那样，小时数似乎是一个异常高的分辨率。如果您坚持这样做，将一天中的时间设置为单独的维度可能会有所帮助，但我无法告诉您这是否是好的设计。
【讨论】：
DateTime 维度，它会扩展为Date 维度？这些似乎比单独的 Date 和 Time 维度更麻烦，但我对你看到的优势很感兴趣。
我建议为日期和时间设置单独的维度。日期维度将有每个日期的 1 条记录作为已识别的有效日期范围的一部分。例如：1980 年 1 月 1 日至 2025 年 12 月 31 日。
还有一个单独的时间维度，有 86400 条记录，每秒有一条由时间键标识的记录。
在您需要日期和时间的事实记录中，添加具有对这些一致维度的引用的两个键。
【讨论】：