通过使用特殊的表值函数(TVF),它允许用户查询此数据,使得可以获取特定表上的所有更改,或者仅在特定时间内获得由更改产生的净更改.
CDC具有一定的优势
>它可以配置为仅跟踪某些表或列.
>它能够在一定程度上处理模型更改.
>它不像触发器那样影响性能,因为它与事务日志一起使用.
>它很容易启用/禁用,并且不需要应该跟踪的表上的其他列.
它也有一些缺点：
>历史数据量可以快速增长.
>您无法跟踪进行更改的人员(至少不会删除更改).
> The history data takes some time to catch up,because it is based on the transaction logs.
>这取决于sql Server代理.如果代理未运行或崩溃,则不会跟踪任何历史记录.
我已经阅读了很多关于CDC的内容,虽然我现在知道如何使用它,但我仍然不确定它是否适合我.
>对于哪些任务/方案,CDC是正确的工具？ (例如,允许用户将数据对象还原到某个特定时间点？审核？显示数据的完整历史记录？)
>您何时应该不使用CDC,而是采用基于触发器的自定义解决方案？
>在运营数据库中使用CDC并在运营应用程序中使用CDC数据是否可以？ (例如,向最终用户显示)或者这显然是对此功能的误用？
我经常听说CDC是一种审计工具,但不是SQL Server Audit的用途吗？它们是同一任务的不同工具吗？或者CDC可以用于其他事情吗？
我目前的情况是,我被要求建立一个可靠的数据框架,该框架应该是未来多个应用程序的基础.确切的要求是模糊的,但一个是它应该能够跟踪数据历史记录并将旧条目与其他表中的所有相关数据一起恢复.我现在正在评估CDC作为一种选择,但我不确定这是否可行,因为我无法找到任何推荐的用例.
虽然我很欣赏针对我的具体方案的建议,但答案应该提供有关何时或何时不使用变更数据捕获的一般建议.
解决方法
Change data capture is available only on the Enterprise,Developer,
and Evaluation editions of sql Server.
因此,如果您的任何客户没有企业版,或者您还不知道您将使用企业版,那么可以决定您. (由于规范包含“多个未来的应用程序”,这可能是一个真正的问题)
与触发器不同,它不是实时的,这既是优点也是缺点.使用触发器总是会降低更新速度.
当我们使用触发器(由CodeSmith生成)时,我在一个系统上工作,以及跟踪记录的所有更改,我们还将更改链接到“历史”表,其中包括进行更改的应用程序的模块,以及用户用于进行更改的UI项.
但是,您可能最好在应用程序级别解决此问题,方法是将所有更新写入消息队列,然后重播以在任何给定时间点创建数据库,有关选项的详细概述,请参阅Temporal Patterns on Martin Flowler blog.
