Question

作为一名数据库用户，我在解决工作中某个表格中的数据时遇到了问题。当我询问数据团队时，解决方案架构师告诉我它是故意这样做的，因为它是一个＆＃34; Type 6＆＃34;表

从我有限的谷歌搜索，我认为类型6应该是这样的：

+--------------+------------------+------------------+------------+------------+---------------------+
| Customer_Key | Customer_Attrib1 | Customer_Attrib2 | Start_Date | End_Date   | Record Updated Date |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 1/1/2001   | 6/8/2004   | 6/9/2004            |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 6/9/2004   | 4/11/2016  | 4/12/2016           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 4/12/2016  | 4/3/2017   | 4/4/2017            |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 4/4/2017   | 5/18/2017  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 5/19/2017  | 12/31/9999 | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+

有问题的活动是Customer_Attrib1，它在2017年5月18日从1变为2。

我喜欢这种风格，因为我可以通过使用开始和结束日期来确定customer_attrib1在任何时间点：

select customer_attrib1 
from table 
where customer_key=123 
and '2017-03-01' between start_date and end_date;

...然而

表本身实际上会更新欠款，如下所示：

+--------------+------------------+------------------+------------+------------+---------------------+
| Customer_Key | Customer_Attrib1 | Customer_Attrib2 | Start_Date | End_Date   | Record Updated Date |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 1/1/2001   | 6/8/2004   | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 6/9/2004   | 4/11/2016  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 4/12/2016  | 4/3/2017   | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 4/4/2017   | 5/18/2017  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 5/19/2017  | 12/31/9999 | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+

如果我想在2016年3月找到customer_attrib1的内容，你能看到我有多麻烦吗？

注意：是一个previous_customer_attrib1列，但它也会大规模更新为值1.我希望保持表足够小以获得重点，这就是为什么我没有＆＃ 39; t将其添加到上面。

重大问题：这是一个有效的仓储策略吗？这真的是Type 6吗？或者我的解决方案架构师错了。

跟进问题：如果customer_attrib1是另一个表的外键，答案是否会有所不同？

Answer 1

你的第一个例子看起来像一个普通的2型SCD。第二个示例看起来像属性1上的类型1（覆盖）和属性2上的类型2 SCD。

也没有提供类型6，这是您可以通过持有方式查看更改历史记录（按照第2个方式，根据您的第一个示例）以及当前值的方式当前值的单独列集，或链接到当前记录。你提到了之前的attrib 1专栏，这对于它是一个类型6是至关重要的。但是你不会期望它也是批量更新的，否则你只是得到一个以前的值，而你不能看到之前的任何变化。

不同的人指的是类型6意味着不同的东西。类型6中您需要的只是值本身（适用于当时的行）和当前值（当发生更改时批量更新），以及（当然）类型2创建方法每次更改的新行。

要回答你的问题，是的，我可以看到你给你的设计带来了多少麻烦。当且仅当它符合业务要求时，它才是有效的策略。这些技术仅用于帮助满足业务需求。

如果该属性是外键，那么它会变得有点棘手，而且我们需要更多关于该外键控表如何跟踪历史记录的信息，以便能够回答是否会改变任何内容。

有效的仓储策略？ TYPE6？

1 个答案: