为什么datekey实际上表总是INT？

Question

我正在查看datekey中事实表格中的AdventureWorksDW列，并且它们都是int类型的所有内容。

是否有理由而不是date类型？

据我所知，创建由INT组成的聚簇索引可以优化查询速度。但是，让我们说我想从上周获取数据。我可以从日期20170704中减去6，并且我将获得20170698这不是有效日期。因此，我必须将所有内容转换为date，减去，然后转换为int。

现在我有一个外键约束，以确保除了＆YYYYMMDD＆＃39;之外的其他内容。没有插入。使用Date类型不是必需的。刚才，我想在6/28和7/4之间获得一些数据。我不能从20170703＆＃39;中减去6。我必须从int转换到日期。

这似乎很麻烦，并没有多少好处。

感谢。

Answer 1

是的，您可以使用日期数据类型并将其作为事实和维度中的主键，并且您将在此过程中保存一个字节。

然后，您将不得不处理已记录的销售，我们也不知道日期。然后怎样呢？在＆＃34;正常＆＃34;维度模型，您定义未知的代理值，以便人们知道有数据，它可能是有用的，但它不完整。常见的惯例是使其为零或在负区域。容易用整数。

日期有点奇怪，因为我们通常使用智能键 - yyyymmdd。从调试的角度来看，很容易快速识别日期，而不必查看您的维度。

您无法生成无效日期。那么什么呢？每个人都知道＆＃34; 1899-12-31是＆＃34;假的＆＃34;约会（或者你想象中的任何痒痒），这一切都很好，直到有人指责约会并神奇地击中你的哨兵日期，现在你已经得到了有效的未知数，只有糟糕的数据输入。

如果您正在针对智能密钥进行日期计算，那么您做错了。您需要转到数据维度以正确解析值并使用了解日期逻辑的方法，因为它不仅仅是月份长度和闰年计算之类的简单事情而且难看和讨厌。

Answer 2

实际上，事实表与表DimDate有关系，如果你加入那个表，你将获得更多的时间点搜索选项，然后你可以通过添加和删除几天/几个月来获得。

说你需要在5月的第二个星期六的所有订单清单？或者12月最后一周的所有订单？ 还有一些企业将其财政年度调整得不同一些从六月开始，一些从一月开始。

总之，当您需要进行复杂的日期搜索而不进行任何计算，并在DimDate上使用简单的索引搜索时，DimDate可以为您提供灵活性

Answer 3

这是一个很好的问题，但答案取决于您的目标是什么类型的数据仓库。例如，SSAS涵盖表格和多维。

在多维中，您永远不会通过SQL查询事实表本身，因此您需要注意的问题包括：从20170704减去6天实际上永远不会出现。因为在MD SSAS中你可以在维度本身上使用MDX来实现日期逻辑（如上面@ S4V1N的回答所示）。 Calendar.Date.PrevMember（6）。对于更复杂的东西，你可以构建各种日期层次结构，并进入MDX ParallelPeriod和FirstChild等等。

对于您打算与SQL一起使用的数据仓库，您的问题更加紧迫。我认为在那种情况下，@ S4V1N的答案仍然适用：将日期逻辑限制在维度方面

1. 因为它已经实现了（可能还有预建日历和财务层次结构）。
2. 因为你的逻辑操作的行数会减少一个数量级。

我非常高兴能在INT风格的日期上使用事实表：但那是因为我使用的是MD SSAS。可能是AdventureWorksDW最初是用MD SSAS构建的（其中事实表中使用的密钥是否适合SQL是无关紧要的），尽管MS的重点似乎最近已转换为Tabular SSAS。或者，对于日期键使用INT可能是一个“开发人员轻推”的设计决策，旨在阻止事实表本身的日期操作，而不是日期维度。

Answer 4

线程很老，但是我的两分钱。

在我工作的一个客户中，选择的设计是一个int列。给我（之前有人加入）的原因是有来自不同来源的导入 - 一些包括时间信息，一些只提供日期信息（两个字符串，一开始）。

通过使用int键，我们可以在Fact表中的datetime列中保留日期/日期时间信息，同时，第二列只包含日期部分（数据类型：日期/日期时间）并使用它来加入Dim表。这样，（a）聚合/措施将更少涉及（b）我们不会过早地丢弃时间信息，这在某些时候可能是有价值的，并且（c）在那时，如果需要，可以将日期维度重构为包含时间或可以创建新的DateTime维度。

尽管如此，这是可接受的权衡，但可能不是一项普遍的建议。

Answer 5

现在有一个很旧的线程，

对于非日期列，顺序整数键被认为是最佳实践，因为它快速且相当小。封装业务逻辑的自然键可能会随着时间而变化，并且可能需要某种方法来识别该维度的哪个版本以适应缓慢变化的维度。

[https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/dimension-surrogate-key/][1]

理想情况下，为保持一致性，日期维度还应具有顺序整数键，为什么它与众不同？毕竟，调试理论也可以应用于其他（非日期）维度。来自数据仓库工具包，第三版，Kimball＆Ross，第49页（日历日期维）是此评论

为便于分区，可以将日期维的主键设置为 更有意义，例如代表YYYYMMDD的整数，而不是 顺序分配的代理密钥。

尽管我认为这意味着对事实表进行分区。我认为datekey是允许与其他维度保持一致的整数，而不是为了便于表分区而使用的顺序键。