Sql server 如何在SQL Server 2008 R2中捕获表级数据更改？

我将大量数据规范化为100多个表。有多个应用程序可以更改这些表中的基础数据，我希望引发有关这些更改的事件。据我所知，可能的选择有：

更改数据捕获 变更跟踪 在每个表上使用触发器是错误的选项，但可能 如果有人之前已经这样做过，那么有人可以分享这样做的最佳方式吗

---

我最终真正想要的是，如果有一个事务影响了100个表中的12个表，我应该能够冒泡一个事件，而不是12个。假设有并发用户更改这些表。

我可以想到两个选项：

触发器是在DB层捕获更改事件的正确方法 在代码方面，我确保在我的应用程序中，每个表只通过代码中的一个位置进行更改，无论更改是什么，我都将其称为该表的中心，因为它将许多不同的路径引导到一个位置，因此在代码层中以这种方式捕获更改事件变得非常容易

---

一种可能是SQL Server查询通知：

只要您想“批处理”多个更改，我认为您应该遵循更改数据捕获或更改跟踪的路线，这取决于您是否只想知道某些更改或发生了什么更改

它们应该由“轮询”过程使用，您每隔几分钟、几秒钟、几毫秒轮询一次更改？？？并举办活动。这样做的好处是，只要存储上一次轮询的最后一行版本（对于每个表），就可以随时检查自上次轮询以来的更改。您不依赖于实时触发器方法，如果停止，您将永远丢失所有事件。该过程可以在检查每个表的过程中轻松创建，并且只需再增加一个表即可存储每个表的最后一行版本

---

此外，这种方法的开销将由您和轮询频率控制。

您不能依赖2。数据库中的数据通常在应用程序之外更改。否则相信是短视的，这就是为什么db必须强制执行约束、审核、fks等，除非您希望您的数据是坏的。@HLGEM确实取决于应用程序的设计，对吗？我喜欢所有的数据源都只能通过一个地方访问，我同意HLGEM的观点。我们处理一套遗留应用程序，一些C，C++，PowerBUilder和一些SPS是第三方产品的公共接口，我知道，但是我们没有一个监控数据变化的来源。这就是挑战！关于触发2件坏事：1。它们无法管理，有400个表2。它们确实对SQL Server性能有影响。@Rajat Mehta-indid，这改变了情况。尽管如此，我认为触发器是最安全的方式，安全、不快速或可管理，这取决于如何设计触发器。如果设计正确，触发器可以真正快速。Judt因为你认为只有一个来源会进入数据库并不意味着这是真的。我保证没有人通过应用程序进行大型数据更新或插入。只计划影响数据的数据层是愚蠢的。