在SQL Server 2008+中，我们希望能够跟踪运行数据库中"Customers"表的历史更改。
这是一个新表，我们的应用程序控制所有对数据库的写入，所以我们不需要像触发器这样的邪恶黑客。相反，我们将在业务对象层中构建变更跟踪，但是我们需要找出要使用的正确数据库模式。
行数将低于100,000，每条记录的更改次数将平均每年1.5。
我们至少有两种方法来建模:
-
作为一个名为
CustomersHistory的Type 2 slow Changing Dimension表，其中包含EffectiveStartDate、EffectiveEndDate(对于当前版本的客户设置为NULL)的列，以及ChangeReason和ChangedByUsername等审计列。然后，我们将在该表上构建一个Customers视图，该视图被过滤为EffectiveEndDate=NULL。我们应用程序的大多数部分将使用该视图进行查询，只有需要具有历史意识的部分才会查询底层表。为了提高性能，我们可以具体化视图和/或在EffectiveEndDate=NULL上添加一个过滤索引。 -
有单独的审核表。对
Customer记录的每一次更改都会写入Customer表，然后再写入CustomerHistory审计表。
考虑到我们从一张白纸开始，这两种方法的优缺点是什么?你有什么建议吗?
一般来说，SCD Type- II的问题是，如果属性值的平均更改次数非常高，那么最终会得到一个非常庞大的维度表。这个不断增长的维度表与一个巨大的事实表相结合，逐渐降低了查询性能。就像慢性中毒一样…一开始你看不到影响。当你意识到的时候，已经太晚了!
现在我明白了，您将使用EffectiveEndDate = NULL创建一个单独的物化视图，并且将在大多数连接中使用。此外，对于您来说，数据量相对较低(100,000)。平均每年只有1.5次的变化，我不认为数据量/查询性能等在不久的将来会成为你的问题。
换句话说，您的表确实是一个缓慢变化的维度(与快速变化的维度相反——选项#2更适合)。就你的情况而言，我更喜欢选项#1。