日期时间作为仓库 FACT 表中 PK 的一部分

Question

我知道通常将 DateTime 列作为 PK 并不是一个好主意，但是对于我的情况，我认为这比在事实表中使用代理键更有意义。

原因是...

1. 插入到事实表中的数据始终是连续的。即我永远不会插入早于事实表中最后一个值的日期时间值。
2. 日期时间字段不是PK（复合PK）的唯一列，PK当然是它本身和维度FK的代理键。
3. 我查询数据的方式几乎总是基于时间。
4. 事实表上的代理键不会告诉我有关该行的任何信息。每行都已经是唯一的，为了找到特定的事实，我总是首先过滤日期时间和维度中的值。
5. 没有单独的日期时间维度表。现在或在可预见的将来不需要指定时间点等。

旁注 - 时间将采用 UTC 格式并使用 SQL 2008 R2。

我要问的是给出的情况 - 这样做有什么缺点？我会遇到不可预见的问题吗？ 当稍后查询该数据时，这实际上是一件好事吗？

想知道人们对 DateTime 字段作为复合 PK 的第一列的看法。

Answer 1

日期/时间是大多数表中键的组成部分，这几乎是任何数据仓库的基本特征。这没有什么“错”。

代理键通常不应该是表的唯一键，所以也许您的问题实际上是“我也应该在我的表上创建一个代理键吗？”。我的建议是，如果您没有理由创建代理键，那就不要创建。创建代理的时间是当您发现需要它时。

Answer 2

大多数事实表都有复合键和日期时间，或者通常 DateKey, TimeKey 是其中的一部分。其实，很常见。

dimDate 和 dimTime 只是用来避免查询的 WHERE 子句中出现“有趣的”日期时间函数。例如

-- sales on
-- weekends for previous 28 weeks
-- 
select sum(f.SaleAmount)
from factSale as f
join dimDate  as d on d.DateKey = f.DateKey 
where d.IsWeekend = 'yes'
  and d.WeeksAgo between 1 and 28 ;

，在这里我可以在 IsWeekend 和 WeeksAgo （还有 DateKey）上建立索引。如果将它们替换为日期时间函数，这将导致逐行处理。