SQL Server审核同一表中的数据

我正在处理的一个项目要求对记录进行数字“签名”，之后任何修改都会创建该行的新“版本”。由于监管原因，“已签名”记录不能修改，新版本不应经常修改。过去，这样做是通过创建一个单独的日志记录表来实现的，该表与主表具有相同的模式，并带有一些额外的列，用于跟踪修改者和修改时间

然而，在对SharePoint做了一些工作之后，所有数据（包括不同版本）都放在同一个表中，我想到了一种不同的方法，我找不到任何这样做的例子：我可以将行的新版本放在同一个表中，并增加版本号。然后将版本号添加到PK

优点：

• 实现很简单，只需创建一个“代替更新”触发器，该触发器执行插入而不是“签名”行的更新。我可以很容易地在触发器中添加要更新的IsCurrentVersion列
• 查询旧版本很容易，只需使用 我想要的ID允许用户从列表中选择
• 触发器很好，因为它保证了一行在签名时不能更新（出于监管和审计目的）
• 对表的架构更改不必复制到镜像“日志记录”表

缺点：

• 表可能会变大一些，但大多数情况下，记录在“签名”后不会更改。客户估计，在当前使用水平下，每年最多约100000行。SQL Server可以处理数以亿计的行，所以这看起来并不太糟糕
• 索引和性能可能是一个问题。SharePoint将tp_CalculatedVersion int添加到PK，其中最新版本的计算数字始终为0。我也可以这样做，并根据版本号进行计算这对性能有帮助吗？
• 查询数据时还有一个额外的步骤，以确保获得最新版本，但这可以在SP中处理

• 在这种情况下还有哪些缺点。我遗漏了什么吗？？？

---

如果要求不更改签名数据，则应将其移动到另一个表中。事实上，我可能会建议将其移动到另一个数据库/模式，在该数据库/模式中，表上唯一允许的操作是插入和读取记录。如果确实要阻止更新，可以同时使用权限和触发器

你可不想把监管要求搞得乱七八糟。使用主键与版本以及触发器组合的复杂模式表明可能有更简单的方法

历史记录会影响当前记录的性能。如果您最终遇到的情况是每个记录都更改了100次，那么将它们保留在同一个表中只会降低查询速度。当然，您可以采用更复杂的方式，对数据进行分区。最后，解决方案更简单：将无法更改的数据保存在另一个无法更改的表中。你不希望仅仅因为积累了大量的历史就必须升级硬件

---

我还建议在历史记录中包括一个生效日期和结束日期。这将允许您重建特定日期的所有数据，用户可能会发现这在将来很有用。

我以前在企业系统中见过这种模式，但在我看来，它并不成功

• 您在这里混合了两种不同的关注点，即实时数据和审计数据的存储。对该表的查询始终需要记住他们是在查找leaf数据还是在查找审计数据（例如报告）-新的团队成员可能会发现这是不直观的。您可能需要用视图等来封装这种复杂性
• 正如您所提到的，性能始终是一个问题。插入新记录还需要更新以前的记录，以将其标记为不活动。您还可能需要考虑更改聚集索引，以将所有版本保持在同一页上。
• 此表的外键将有问题。你…吗 参考准确的版本记录？那你能修好外轮吗 指向新live leaf记录的键

我认为这样做的一个好处是审计表DDL将始终与活动表同步——通常与2个表同步，对活动表进行策略更改，并且审计和触发DDL不会相应地更新

---

总的来说，我仍然建议将审计表分开。

没错。审计跟踪可以保留在内部报告/审计的应用程序中，但infosec最佳做法要求将审计日志从系统中删除，并将其生成到日志管理/SIEM解决方案中

如果您将“已签名”记录发送到另一个数据库，那么实际上主表中只有“草稿”记录？这意味着表几乎总是空的（对我来说似乎很奇怪）。应该有一个当前表，其中包含所有记录的最新版本，无论是否已签名。历史记录表将维护审计的要求，即所有已签名的记录。好的，我过去就是这样做的，没有额外的数据库。那么你看到的主要缺点是额外的复杂性？额外记录的问题不是问题，因为他们在签名后很少对其进行编辑。@JimBrown。主要缺点是性能和复杂性。复杂的问题是无法满足审计要求，这很难检测和修复。