审计表与类型 2 渐变维度答案

【问题标题】：audit table vs. Type 2 Slowly Changing Dimension审计表与类型 2 渐变维度
【发布时间】：2014-08-11 16:24:24
【问题描述】：

在 SQL Server 2008+ 中，我们希望能够跟踪操作数据库中“客户”表的历史更改。

这是一个新表，我们的应用程序控制所有对数据库的写入，因此我们不需要触发器之类的恶意攻击。相反，我们会将更改跟踪构建到我们的业务对象层中，但我们需要找出要使用的正确数据库模式。

行数将低于 100,000 行，每条记录的更改次数平均为每年 1.5 次。

我们一直在研究建模的方法至少有两种：

作为名为 CustomersHistory 的 Type 2 Slowly Changing Dimension 表，具有 EffectiveStartDate、EffectiveEndDate 的列（对于当前版本的客户，设置为 NULL）和审计列，如 ChangeReason 和ChangedByUsername。然后我们会在该表上构建一个Customers 视图，该表被过滤为EffectiveEndDate=NULL。我们应用程序的大多数部分都将使用该视图进行查询，并且只有需要历史感知的部分才会查询基础表。为了提高性能，我们可以物化视图和/或在 EffectiveEndDate=NULL 上添加过滤索引。
带有单独的审计表。对Customer 记录的每次更改都会写入一次Customer 表，然后再次写入CustomerHistory 审计表。

通过对 StackOverflow 问题的快速回顾，#2 似乎更受欢迎。但这是因为大多数数据库应用程序必须处理遗留和流氓作家吗？

鉴于我们是从一张白纸开始，这两种方法的优缺点是什么？你会推荐哪个？

【问题讨论】：

它是一个 OLTP 数据库而不是一个单独的数据仓库，但有问题的表不会经常更改。
我想应用程序中的一个常见操作将显示给定客户交易的列表。 SCD 2 每次都需要额外的连接 - CustomersCurrentView WHERE Customer = 'John Doe' JOIN CustomersHistory JOIN Transactions。我的建议是——如果不经常使用历史数据，就保留一组单独的审计表；仅当历史感知组件构成应用程序的重要部分时才考虑 SCD 2。为一个非常有趣的问题 +1！

【解决方案1】：

一般来说，SCD Type-II 的问题是，如果属性值的平均变化次数非常高，那么最终您会得到一个非常胖的维度表。这种不断增长的维度表与巨大的事实表相连接，会逐渐降低查询性能。这就像缓慢中毒.. 最初你看不到影响。当你意识到这一点时，为时已晚！

现在我了解到您将使用EffectiveEndDate = NULL 创建一个单独的物化视图，并将用于您的大部分连接。此外，对您而言，数据量相对较低（100,000）。平均每年只有 1.5 次变化，我认为数据量/查询性能等在不久的将来不会成为您的问题。

换句话说，您的表格确实是一个缓慢变化的维度（与 rapidly changing dimension 不同 - 您的选项 #2 更适合）。在你的情况下，我更喜欢选项#1。

【讨论】：