如果源仅用于插入,请为其提供一IDENTITY
列。进行数据传输时,您将记录写入的最高值。在下一次传输期间,您只需要查询大于上一次传输记录的值。我们这样做是为了将日志记录传输到数据仓库。
对于可更新的行,请添加“脏”标志。它将具有三个值-干净,脏和已删除。日常查询将不得不省略标记设置为“已删除”的行。这在维护,测试和运行时将是昂贵的。在大查询之后,您提到必须删除标记为删除的所有行,并为所有其他行重置标志。这将无法很好地扩展。
变更跟踪是更轻松的变更数据捕获替代方案。它不会告诉您哪些值已更改,只是自上次查询以来该行已更改。内置功能有助于检索更改的值并管理跟踪。我们已经成功地使用CT在一个100,000,000行表中每天处理大约100,000个更改。
查询通知仍然在结果集级别上发挥更高的作用。从概念上讲,这就像定义一个视图。如果SQL Server检测到通过该视图返回的任何行已更改,它将向应用程序发送一条消息。没有指示更改了多少行或哪些列。只有一条简单的消息说“发生了什么事”。查询和响应取决于应用程序。正如您所想象的,实际上它要复杂得多。在如何定义查询方面存在一些限制,并且可能会为更改后的数据以外的条件触发通知。通知触发时将其删除。如果随后发生了其他感兴趣的活动,则不会再发送任何消息。
在OP的问题中,QN的优点是安装开销低,运行时成本低。建立和维持严格的订阅消息反应机制可能是一项巨大的努力。由于数据表很大,因此可能会对其进行频繁更改,这意味着该通知很可能在大多数处理周期中触发。由于没有迹象表明增量变化的增量处理将无法实现,就像CT或CDC那样。由于错误触发而造成的开销令人厌烦,但是即使在最坏的情况下,也不必比现在更频繁地运行昂贵的查询。