为什么datekey中的表总是INT？

我在查看AdventureWorksDW事实表中的datekey列，它们都是int类型。为什么datekey中的表总是INT？

是否有这样的原因，而不是类型date？

据我所知，创建一个由INT组成的聚集索引可以优化查询速度。但是，让我们说我想从过去一周获取数据。我可以从的日期减去6，我将得到20170698这不是有效的日期。所以我必须将所有东西都投射到date，减去，然后投射为int。

现在我有一个外键约束，以确保除'YYYYMMDD'之外的东西没有插入。对于Date类型，这不是必需的。刚才，我想在6/28和7/4之间获得一些数据。我不能只从`20170703'减6;我不得不从int到现在。

它看起来很麻烦，没有太多好处。

谢谢。

来源

2017-07-05 rbhat

为什么你认为'int'（4字节）的索引会比'date'数据类型（3字节）更高效？ –

这里有一些讨论http://www.made2mentor.com/2011/05/date-vs-integer-datatypes-as-primary-key-for-date-dimensions/ –

使用代理键有一个重要的好处：如果你决定增加时间维度的粒度（从几天到几个小时），你可以毫不费力地做到这一点，而不必改变现有的数据（是的，我有一个数据仓库的经验）。请注意，我正在讨论一个* surrogate *键，而不是一个'INT'键，它创造性地编码了一个日期，我看不出有什么比实际日期/时间类型更有优势。 –

事实上，事实表与表DimDate有关系，如果您加入该表，您将获得更多的时间点搜索选项，那么如果您通过添加和删除日/月获得更多选项。

假设您需要5月第二个星期六的所有订单清单？或者是12月最后一周的所有订单？另外一些业务规定其财政年度有所不同。一些在6月开始，一些开始在一月..

综上所述，DimDate是那里当你需要做复杂的日期搜索没有做任何的计算，并使用一个简单的索引查找上DimDate

来源

2017-07-05 19:15:06 S4V1N

但日期维度的主键可能是日期而不是整数。问题不在于询问日期维度的用途是什么，而是为什么使用诸如“20170701”这样的整数作为键而不是为日期设计的数据类型。 –

可能是，使用自动生成的不断增加的整数而不是日期只是一种更好的做法。没有特别的理由 – S4V1N

所以这是“更好的做法”，但没有“特别的原因”？这不是一个令人信服的论点。为什么更好的练习？ –

为您提供灵活性

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

然后你将不得不处理记录的销售，我们不知道日期。然后怎样呢？在“正常”维模型中，您可以定义“未知”替代值，以便人们知道有数据，可能有用，但不完整。一个共同的惯例是使其为零或在负面领域。易于使用整数。

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

您无法制作无效日期。 Soooo然后呢？每个人都“知道”1899-12-31是“虚假”的日期（或任何你想象中的痒痒），这一切都很好，直到有人发指令约会，神奇地撞上你的哨兵约会，现在你已经混合了有效的未知数只有不好的数据输入。

如果你正在对智能钥匙进行日期计算，那么你做错了。您需要转到数据维度以正确解析该值并使用能够识别日期逻辑的方法，因为它不仅仅是简单的事情，例如月份长度和闰年计算，而且还很丑陋。

来源

2017-07-05 21:08:55 billinkc

我不是真的把这当作**好的理由来购买。在输入典型的商业日期时，胖指法'1899-12-31'会很难做到。我不认为应该使用数据类型来预测数据输入错误的可能性。胖手指'2017-07-01'而不是'2017-06-01'很容易，为什么肥胖指责一个未知的日期更多的问题？如果你真的想避免胖手指的错误，那么也许你应该使用Guid而不是智能钥匙（或者至少键入一定的levenshtein距离）。当然，没有人会这样做。 –

在我们的案例中，没有数据输入。我们从Oracle表导入大量数据，并确保日期正确，因为Oracle表中的列也是'DATE（7）' – rbhat

这是一个很好的问题，但答案取决于你想要的数据仓库类型。例如，SSAS涵盖了表格和多维度。

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

对于您打算使用SQL的数据仓库，您的问题更具紧迫性。我认为，在这种情况下，@ S4V1N的回答仍然适用：限制您的日期逻辑维度侧

，因为那是它已经实现（可能带有预建的日历和财政层级）。
因为你的逻辑将在一个数量级以下的行上操作。

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

来源

2017-07-06 16:21:21 SebTHU

类型的列谢谢您的答复。我们的数据库最初是一个关系数据库，并且由于正在请求报告，我正在测试SSDT。但我一定会用常规的tsql查询。 – rbhat

线程很旧，但我的两美分。

在我工作的客户之一，所选的设计是一个int列。（我加入之前由某人提供）的理由是，有来自不同来源的进口 - 一些包括时间信息，另一些只提供日期信息（两个字符串，首先）。

通过使用int键，我们可以在Fact表的日期时间列中保留日期/日期时间信息，同时只有日期部分的第二列（数据类型：日期/日期时间）并使用它来加入Dim表。（b）我们不会过早地丢弃时间信息，这在某些时候可能是有价值的;（c）在这一点上，如果需要，可以将日期维度重构为包括时间或者可以创建新的DateTime维度。

这就是说，这是公认的权衡，但可能不是一个普遍的建议。

来源

2018-02-09 08:18:36

为什么datekey中的表总是INT？

回答

相关问题