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

我通常知道将DateTime列作为PK是不太好的想法，但对于我的情况，我认为它比事实表中的代理键更有意义。DateTime作为仓库的FACT表中的PK的一部分

的原因是...

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

副笔记 - 时间将在UTC和使用SQL 2008 R2。

我在问的是给出的情况 - 这样做的缺点是什么？我会遇到无法预料的问题吗？以后再查询这些数据时，这样做是件好事吗？

想知道DateTime字段上的人物视点作为复合PK的第一列。

来源

2011-05-27 Gary Howlett

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

一个代理键通常不应该是只有表的关键，所以也许你的问题是“我是否也应该在我的表上创建一个代理键？”。我的建议是，如果你没有理由创建代理键，那么不要。创建代理人的时间是当你发现你需要它的时候。

来源

2011-05-27 10:55:12 sqlvogel

我一直在做一些思考 - 具体围绕页面拆分。我看到了数据可能不会顺序进入事实数据表的情况，即一些旧数据可能会进入事实。如果PK先在日期聚集，那么页面可能需要重新组织。因此，我认为我会把PK作为日期时间和FK的维度，但不要将它聚集在一起。然后生病有一个代理键（身份）作为群集索引 - 即使生病可能永远不会在我的任何查询中使用它。这应该会带来更快插入的优点，并且quesring应该具有相同的速度。 – 2011-05-27 13:11:24

定义密钥是逻辑设计的问题。定义群集是一个物理设计问题。不要混淆两者。并且将历史数据聚集在任何你所保存历史记录的对象身上，实际上可能使阅读顺序更快，而不仅仅是“等速”！ – 2011-05-27 14:06:23

大多数事实表具有复合键和日期时间，或者通常是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太）。如果这些被日期时间函数替代，则会导致逐行处理。

来源

2011-05-27 12:54:12

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

回答

相关问题