6

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

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

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

我们至少有两种方法来对此建模：

  1. 作为名为 的类型 2 渐变维度表，其中包含、CustomersHistory的列（针对客户的当前版本设置为）和审计列，例如和。然后我们会在该表上构建一个视图，该视图被过滤为. 我们应用程序的大多数部分都将使用该视图进行查询，并且只有需要历史感知的部分才会查询基础表。为了提高性能，我们可以物化视图和/或在 EffectiveEndDate=NULL 上添加过滤索引。EffectiveStartDateEffectiveEndDateNULLChangeReasonChangedByUsernameCustomersEffectiveEndDate=NULL

  2. 带有单独的审计表。对记录的每次更改都会Customer写入Customer表一次，然后再写入CustomerHistory审计表。

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

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

4

1 回答 1

2

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

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

换句话说，您的表格确实是一个缓慢变化的维度（与快速变化的维度相反——您的选项#2 更适合）。就您而言，我更喜欢选项＃1。

于 2014-06-28T04:25:57.033 回答