我正在尝试彻底检查我的 CRUD 应用程序的日志架构。它是一个带有 SQL Server 2008 R2 后端的 .NET Winforms 应用程序。
在当前设置中，只要用户按下“保存按钮”，就会调用数据库日志。变更集是使用 .NET 反射在代表我们存储在 SQL 中的表的类上确定的。
日志存储在名为 ActionLogHeader 和 ActionLogDetail 的两个表中。
header 架构:
ActionLogHeader_id |表名 |主键 | Action 类型 |用户 | Action 日期
详细架构:
ActionLogDetail_id | ActionLogHeader_id |专栏已更改 |预值 |后值
一个 Header 可以有多个 Details。每个详细信息行代表表中更改的单个列。 ActionType 是插入/更新/删除/查看。
这通常适用于向用户显示我们数据库中任何事物发生的更改列表。但是，很难从中提取数据来创建一个事物在任何时刻的样子的完整图片。很难针对特定数据点汇总此数据。
我们探索过将这些数据从 SQL Server 移出并移入 Hadoop/HBase，但我觉得我们所做的只是在不更改结构的情况下移动数据。我们已将表展平并添加了更多列，因此从 SQL 获取数据不会成为问题。但是对数据进行任何类型的分析仍然需要一个 MapReduce 作业，这很难设置。
所以我对其他人在日志记录方面所做的事情很感兴趣。有更好的策略吗？我已经看到很多人喜欢在数据库级别使用触发器来记录一些变更日志，但我不知道这对性能有何影响。我不确定从这里去哪里。
最佳答案
查看变更数据捕获 Microsoft CDC docs"看看你是否可以使用它而不是自己滚动。还有一个article that covers the basics of CDC这作为概述很有用。当然，无论你做什么，都会有开销。
如果您尝试仅记录来自您的应用程序的内容，您的方法会更可取。
有些人还使用使用事务日志 (.ldf) 进行数据库更改审计的第 3 方工具。
已添加
记住这篇文章，回复 CDC performance.如果 MS 值得信赖，那么性能应该比大多数推出自己的解决方案更好。当然，要证明这一点，您必须亲自动手并进行比较。文章关键段落:
更改数据捕获可以通过异步读取源数据库的事务日志来捕获源系统中的更改。为此，更改数据捕获使用与事务复制中使用的相同的日志读取器。由于更改数据捕获适用于现有表架构，因此无需更改源数据库或应用程序即可启用更改数据捕获。由于日志读取器作业异步工作，因此 DML 事务受到的影响远小于触发器等同步解决方案。对源表的所有更改都记录在特殊的更改表中，因此无需比较源系统和目标系统的更改。
已添加
其他选择。
好吧，您可以像您提到的那样编写触发器等来捕获所有数据更改，从而降低服务器速度、调试问题等。您可以使用第 3 方 tranlog 分析器 (Apex) 来分析日志，您可以继续沿着你当前的路径前进，或者你可以升级到企业版。没有成本和/或努力，没有什么能神奇地让一切变得美好。
还有其他有效的方法。
查看类似问题的先前答案
关于.net - CRUD 应用程序日志记录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25191272/