我正在尝试彻底检查我的CRUD应用程序的日志记录架构。它是一个带有SQL Server 2008 R2后端的.NET Winforms应用程序。
在当前设置中，只要用户按下“保存按钮”，就会调用数据库日志。使用.NET反射确定变更集，这些类表示我们存储在SQL中的表。
日志存储在两个名为ActionLogHeader和ActionLogDetail的表中。
标题架构：
ActionLogHeader_id | TableName | PrimaryKey | ActionType | User | ActionDate
详细模式：
ActionLogDetail_id | ActionLogHeader_id | ColumnChanged | PreValue | PostValue
单个标题可以有多个详细信息。每个详细信息行表示在表中更改的单个列。 ActionType是insert / update / delete / view。
这通常用于向用户显示发生在我们数据库中任何一件事情上的更改列表。但是很难从中提取数据来创建一个完整的图片，显示任何时间内某些东西的样子。针对特定数据点聚合此数据很困难。
我们已经探索过将这些数据从SQL Server迁移到Hadoop / HBase，但我觉得我们所做的就是在不改变结构的情况下移动数据。我们已经将表格弄平并添加了更多列，因此从SQL中获取数据不会成为问题。但是对数据进行任何类型的分析仍然需要MapReduce工作，这是一个很难设置的工作。
所以我对其他人正在做的日志记录感兴趣。有更好的策略吗？我已经看到很多人喜欢在数据库级别触发某些更改日志，但我不知道这会如何影响性能。我不确定从哪里开始。
答案 0 :(得分：3)
查看更改数据捕获Microsoft CDC docs"，看看您是否可以使用它而不是自己滚动。还有一个article that covers the basics of CDC作为概述很有用。当然，无论你做什么都会有开销。
如果您只想记录来自您的应用程序的内容，那么您的方法将更为可取。
有些人还使用使用事务日志（.ldf）进行数据库更改审核的第3方工具。
ADDED
记住这篇文章，重新CDC performance.如果MS可以信任，那么应该比大多数人更好地推出自己的解决方案。当然要证明这一点，你必须自己动手并进行比较。文章中的关键段落：
更改数据捕获可以通过异步读取源数据库的事务日志来捕获源系统中的更改。为此，更改数据捕获使用与事务复制中使用的相同的日志读取器。由于更改数据捕获适用于现有表模式，因此无需更改源数据库或应用程序以启用更改数据捕获。由于日志读取器作业异步工作，因此与触发器等同步解决方案相比，DML事务的影响要小得多。对源表的所有更改都记录在特殊更改表中，因此不需要在源系统和目标系统之间进行更改以进行更改。
ADDED
其他替代方案。
好吧，您可以编写触发器等，如上所述捕获所有数据更改，减慢服务器速度，调试问题等。您可以使用分析日志的第三方tranlog分析器（Apex），您可以继续沿着当前路径延伸，或者您可以升级到企业版。没有成本和/或努力，没有什么能够神奇地使一切变得美妙。
还有其他有效的方法。
查看类似问题的先前答案