Datawarehouse性能差异非规范化时间

Question

在书中我读到，如果将时间分成单独的列，那么它就是一个真正的性能提升者。 e.g日，月，年等...

1. 不要数据库已经为处理indicies随着时间的推移列，使分裂的时间和增加指数的数以百万计variantes是过时的一些智能计算策略？

2. 性能差异的任何体验？

可能的查询是周一上午13：00-14：00之间的销售。

Answer 1

看一看this SO question/answer。

Answer 2

您对大纲（每个星期一13：00-14：00）的具体情况不能由日期时间数据的正常索引正确提供。

这将需要大量解析日期时间数据到星期几+时间部分来获取该信息。对于这种情况，将其分成一周中的一天和另一天中的一小时（小时）会更好，并且可以单独编制索引或作为复合索引（跨两者）。

表现非常不同 - 不是用数据的1/168（理论上的平均值）或更真实地用数据（工作小时数）的1/50来查看使用周日期+时间的指数的数据那么查询将不得不运行2次转换（以获得星期+时间组件），然后通过过滤器运行该转换。

Answer 3

在许多星型模式中，有一个时间维度是有用的。在该维度表中，明确规定星期几，月份等是非常有用的。许多这些属性可以通过您的SQL方言中的内置函数来访问。如果使用这些函数，那么它比使用这些数据时占用的磁盘I/O少。但是，如果日历功能看起来像数据一样，那么在给定时间片上撰写报告的艺术就会变得更加容易。

如果这可能真的有用，那么您的企业是否有一个特殊的“公司canlendar”，日期可以属于称为“财政季度”的单位，这些单位不容易映射到日 - 月 - 年。如果将所有日历怪癖都放入一个生成时间维度表的程序中，它可以使您的仓库代码的其余部分更加清洁。

与任何维度表一样，正确设置粒度非常重要。如果你每天只需要一行，你可以存储10年的日期，只有超过3650行，这是按照今天的标准来看的一个小表格。在某些情况下，“转变”（一个8小时的时间段）证明是正确的粒度。这取决于数据的用途。

无论你走哪条路，都要为数据做好准备，以便在建立仓库时进行“变态”，并在遇到意外要求时准备面对“试用”。

Answer 4

基于函数的索引是一种可能的选择。索引视图是另一个视图。

只是创建一个新的属性不是提高性能的东西。任何性能差异都是由于数据存储和索引方式的根本变化造成的。因此，说创建单独的日期和时间列是一种表现助推器，这是误导性和过于简单化的。但是，创建单独的时间列可能是其他原因的好主意，例如：清晰度，简化查询逻辑或充分利用DBMS日期/时间类型和其他功能。