在SQL Server 2008+中，我们希望启用对运营数据库中“客户”表的历史更改的跟踪。
这是一个新表，我们的应用程序控制着对数据库的所有写入，因此我们不需要像触发器这样的邪恶黑客。相反，我们会将更改跟踪构建到业务对象层，但我们需要找出要使用的正确数据库模式。
行数将低于100,000，每条记录的变化数量平均为每年1.5。
我们至少有两种方法可以对此进行建模：
作为名为CustomersHistory的{{3}}表，其中包含EffectiveStartDate，EffectiveEndDate的列（对于当前版本的客户，设置为NULL ），以及审核ChangeReason和ChangedByUsername等列。然后我们在该表上构建一个Customers视图，该视图被过滤到EffectiveEndDate=NULL。我们的应用程序的大多数部分将使用该视图进行查询，并且只有需要具有历史记录功能的部分才会查询基础表。为了提高性能，我们可以实现视图和/或在EffectiveEndDate = NULL上添加过滤索引。
使用单独的审计表。对Customer记录的每次更改都会向Customer表写入一次，并再次写入CustomerHistory审计表。
通过对StackOverflow问题的快速回顾，＃2似乎更受欢迎。但这是因为大多数数据库应用程序必须处理遗留和流氓作家吗？
鉴于我们从一个空白的平板开始，这两种方法的优点和缺点是什么？你会推荐哪一个？
答案 0 :(得分：2)
一般来说，SCD Type-II的问题是，如果属性值的平均变化次数非常高，那么最终会有一个非常胖的维度表。这个不断增长的维度表与一个巨大的事实表相结合，逐渐降低了查询性能。这就像慢中毒一样。最初你没有看到影响。当你意识到这一点时，为时已晚！
现在我知道您将使用EffectiveEndDate = NULL创建一个单独的物化视图，并将在大多数连接中使用。另外，对于您来说，数据量相对较低（100,000）。平均每年只有1.5的变化，我不认为数据量/查询性能等将在不久的将来成为您的问题。
换句话说，您的表格确实是缓慢更改维度（而不是rapidly changing dimension - 您的选项＃2更适合）。在您的情况下，我更喜欢选项＃1。