如何记录 sql server 表中更改的数据。哪种方法更好答案

【问题标题】：How to log data changed in sql server tables. Which approach is better如何记录 sql server 表中更改的数据。哪种方法更好
【发布时间】：2011-09-01 09:20:49
【问题描述】：

只是想了解日志数据修改。

我已经了解了跟踪数据更改 (DML) 的方法。

使用触发器
将添加日期、添加者、修改日期、修改者的列保留在同一个表中。

使用方法 (1)，我可以在每个表上编写插入/删除/更新触发器以记录更改，因此可以根据要求在所有表上应用外键关系和其他约束，例如唯一键约束。

但我不明白如何使用方法 (2) 应用各种约束。因为我必须制作复合唯一键并且必须考虑更多列。

数据库表中是否存在任何设计问题。方法（2）记录数据的建议方式是什么。

哪种方法更好。

另外，我从我的一些同事那里了解到，触发器不会在批量插入查询中触发，这是真的吗？

【问题讨论】：

好问题，我已经看到/使用了这两种方法，但似乎都不对，我认为 rdbms 应该提供一些内置功能。
在 Sql Server 2008 中，引入了一个新功能，即提供相同功能的 CDC“更改数据捕获”。但我担心以前的版本。
CDC 会告诉您发生了什么变化（包括实际数据），更改跟踪会告诉您哪些行发生了变化，但都不会告诉您是谁做的。审计可能是您唯一避免触发的内置功能，但它需要 Enterprise。对于您的 2. 如果您不使用触发器，您如何捕获临时更新的信息？
默认情况下，在 BULK INSERT 期间将忽略触发器，但有一个 FIRE_TRIGGERS 选项。这样做当然会抵消使用批量插入的大部分好处，特别是如果您的触发器效率低下。
所以您一直为每次更改保留一行？这听起来根本不是最佳选择。我宁愿在别处存档历史记录，也不愿污染主表。

标签： sql-server database performance

【解决方案1】：

我最喜欢的解决方案是要求（如果可能，使用安全功能）所有应用程序数据访问（或至少所有 CRUD 操作）都经过存储过程，并让 SP 管理更改跟踪和审计。

触发器的问题在于它们不能很好地扩展；它们可以通过将批量插入或更新转换为许多单行操作来对性能造成重大影响。

至于是将更改保留在行中还是在另一个表中，我的偏好是使用另一个表。这样，我还可以在需要时了解实际更改的历史，而不仅仅是谁和何时。保持源表窄也有助于提高查询/读取性能。

您还可以对审计表应用分区，这将使它们在时机成熟时易于老化/删除。

【讨论】：

【解决方案2】：

你错过了一个重要的：Change Data Capture。 Sql Server 企业版已经内置了这个功能。

【讨论】：

谢谢。唯一的问题是我们将根据客户更改我们的数据库服务器。所以我们试图尽可能减少对数据库服务器的依赖。但感谢您提出这一点。