DateTime作为仓库FACT表中PK的一部分

Question

我一般都知道将一个DateTime列作为你的PK并不是一个好主意，但是对于我的情况，我认为它比在Fact Table中有一个代理键更有意义。

原因是......

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

附注 - 时间将采用UTC并使用SQL 2008 R2。

我所要求的是提供这种情况 - 这样做有什么不利之处？我会遇到不可预见的问题吗？ 在稍后查询数据时，这是否是一件好事？

想知道人们在DateTime字段上的观点作为复合PK的第一列。

Answer 1

几乎所有数据仓库的基本功能都是日期/时间是大多数表中键的一个组成部分。这没有什么“错误”。

代理键通常不应该是表的 only 键，所以也许你的问题确实是“我应该在桌面上创建代理键吗？”。我的建议是，如果你没有理由创建一个代理密钥，那就不要了。创建代理人的时间就是当你发现需要时。

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）上建立索引。如果这些被日期时间函数替换，则会导致逐行处理。