在我读到的书中，如果你将时间分成单独的列，它是一个真正的性能提升器。例如日、月、年等...
数据库是否已经有一些智能方法来处理时间列上的索引，因此拆分时间并添加数百万个索引变体已经过时了？
在性能差异方面有任何经验吗？
一个可能的查询是星期一早上 13:00-14:00 点之间的销售。
问问题
317 次
4 回答
2
于 2011-03-04T12:23:37.260 回答
0
您概述的特定场景（每周一 13:00-14:00）无法由针对日期时间数据的普通索引正确提供。
这将需要将日期时间数据大量剖析到星期几+时间部分才能获得该信息。对于这种情况，将它分成一周中的某一天和一天中的时间（小时）的另一列会更好，并且可以单独索引或作为复合索引（跨两者）。
性能是非常不同的 - 而不是查看 1/168 的数据（理论平均值）或更实际地大约 1/50 的数据（工作时间），使用基于星期几 + 时间的索引，查询否则必须运行 2 次转换（以获得星期几 + 时间组件），然后通过过滤器运行它。
于 2011-03-04T11:16:55.667 回答
0
在许多星型模式中，具有时间维度很有用。在该维度表中，明确列出星期几、月份等会很有用。其中许多属性可以通过 SQL 方言中的内置函数访问。如果你使用这些函数，它需要的磁盘 I/O 比你具体化这些数据要少。但是，如果日历功能看起来像数据，它会使在给定时间段内编写报告的艺术变得更加容易。
这可能真正有用的地方是您的企业有一个特殊的“公司日历”，其中日期可以属于称为“财政季度”的单位，这些单位不容易映射到日-月-年。如果您将所有日历怪癖放入一个生成时间维度表的程序中，它可以使您的仓库代码的其余部分变得更加简洁。
与任何维度表一样，正确设置粒度非常重要。如果您每天只需要一行，您可以存储超过 3,650 行的十年日期，按照今天的标准，这是一张很小的表。在某些情况下，“班次”（8 小时的周期）被证明是正确的粒度。这取决于数据的用途。
无论走哪条路，在建仓时做好数据“蜕变”的准备，在遇到突发需求时做好“试炼”的准备。
于 2011-03-04T11:30:57.050 回答
0
基于函数的索引是一种可能的选择。索引视图是另一个。
仅仅创建一个新属性并不能提高性能。任何性能差异都是由于数据存储和索引方式的潜在变化造成的。因此，说创建单独的日期和时间列是性能提升器是一种误导并且过于简单化。但是，出于其他原因，创建单独的时间列可能是一个好主意，例如：清晰、简化查询逻辑或充分利用 DBMS 日期/时间类型和其他功能。
于 2011-03-04T11:43:20.300 回答