审计表结构答案

【问题标题】：audit table structure审计表结构
【发布时间】：2010-11-18 21:36:23
【问题描述】：

我正在为我的数据库构建审计表，并且需要选择要实现的样式。我目前正在考虑三个选项，所有这些选项都将使用触发器填充：

具有字段 id 的单个表 |表|专栏 |行 |旧值 |新值 |时间戳 |用户身份。这将在一个地方跟踪所有表的所有更改，并有利于最大限度地减少表的数量。这确实使查询有点困难，但并非不可能。
多个表，如 #1，但没有表列。这会将每个表中的更改分离到它们自己的历史表中。
镜像要跟踪的原始表的架构的多个表。这将使触发器更容易编写，如果有人想恢复到特定记录，会使数据恢复更容易，但会以存储为代价，因为每个字段，即使它没有改变，也会被复制，可能多次。此外，很难具体了解哪些字段从一个版本更改为下一个版本。

这三个选项中的每一个都是可行的，据我所知，没有一个提供的功能在另一个选项中是不可能的。所以一定有一些我没有考虑的东西或者一些更标准的模式。如果有什么不同，这个解决方案必须同时适用于 mysql 和 sql server（虽然我可以稍后制定代码的细节）。

【问题讨论】：

我实现了3号的版本。在SQL Server中，触发器可以识别出每一列已经被修改过。我将它与修改的整行 + 一些审计特定列（审计日期时间、用户信息等）一起存储。我存储散列，但创建一个视图来解码散列并列出受影响的列。

【解决方案1】：

审核表受到非常严重的影响，您不希望所有审核都只使用一个表，否则您将被阻塞。

除了每个表有两个表（一个存储更改实例，另一个存储实际数据）之外，我们执行第二个类似的操作。这样可以轻松找到存储在百万条记录中的所有记录导入到一个表中实例，因为它们都是同一个实例。这意味着我们可以在添加新表时轻松编写新审计表的脚本。

在第二个的情况下，我建议编写一个过程来恢复特定的记录，这样恢复很容易，你不必每次都弄清楚。

【讨论】：

HLGEM 提出了一个很好的观点。出于性能原因将其拆分很有意义，如果您有大量的读/写（每天数百万）或大批量更新，那么 HLGEM 的解决方案是一个很好的解决方案。但是，如果您的需求不是那么高，那么选项 1 是性能和维护之间的一个很好的折衷方案。数据库可以处理很多事情，根据具体情况，过分强调优化可能是错误的。
哦，所以如果用户更新一行的 5 个字段，那么一个表会获得一个新的更改实例，而另一个表会获得 5 个新的更新行，都链接到该实例？这确实使恢复更容易。
实际上，由于我们对每个审计表使用相同的结构，我们能够自动创建新的审计表，因此我们几乎不需要维护。它们不会因每个表而改变，我们的工作是搜索新表并创建审计表和触发器来维护它们。
我真的很喜欢这个答案。它似乎可以处理我们想要完成的所有事情。对于具有旧/新值的表，您如何处理数据类型？您是否只是将该列作为 varchar(max) 并将所有数据类型转换为文本/从文本转换？
是的，该列是 nvarchar(max) 。一定要写一个进程来检索特定数据以重新插入到表中，这种结构有点复杂，所以最好不要试图弄清楚在需要恢复10000条用户记录的压力下，有人不小心删除了。

【解决方案2】：

不是答案，只是进一步的问题：您的审计表的目的是什么？为什么你想要它们，需要它们，或者必须拥有它们？他们将如何使用，他们将回答什么问题或他们将解决什么情况？它们的使用频率是多少？您必须将这些数据保留多长时间？到期后您将如何清除或归档这些数据？

前面的两个答案 [theChrisKen, HLGEM] 不同意，但是——基于他们之前的工作——我敢打赌他们都是正确的。如果您考虑如何使用它们以及该使用的性能要求，它们可能会帮助您确定哪种模型最适合您的情况。

【讨论】：

它们将用于 1) 向订阅用户发出更改通知（以瞬时、每日、每周或每月的频率） 2) 在记录本身旁边显示对记录的更改表 3 ) 如果更改不正确或不适当，则恢复到以前的版本。数据是记录的一部分，永远不会被清除。我可以看到 theChrisKen 和 HLGEM 如何找到适合不同条件的解决方案。我们希望有一个可以很好地扩展的解决方案，尽管它不会超过几百个用户（一次

【解决方案3】：

我会选择 1 号。如果您决定在跟踪中添加其他字段并且除了删除 WHERE table=?条款。 3号是多余的。这就是备份的用途。

【讨论】：