3

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

但是，在使用 SharePoint 进行一些工作后，将所有数据（包括不同版本）放入同一个表中，我想到了一种不同的方法，我找不到任何人这样做的例子：我可以把新版本的行放在右边在同一个表中并增加版本号。然后将版本号添加到PK。

优点：

  • 实现很简单，只需创建一个“代替更新”触发器，它执行插入而不是更新行是“签名的”。我可以轻松地在触发器中添加要更新的 IsCurrentVersion 列。
  • 查询旧版本很容易，只需获取具有我想要的 ID 的所有记录，让用户从列表中选择。
  • 触发器很好，因为它保证如果签名后行不能被更新（出于监管和审计目的）。
  • 不必将表的模式更改复制到镜像“记录”表。

缺点：

  • 该表可能会变大一些，但大多数情况下，“签名”后记录不会更改。客户估计在当前使用水平下每年最多 100,000 行。SQL Server 可以处理数亿行，所以这看起来还不错。
  • 索引和性能可能是一个问题。SharePoint 将 tp_CalculatedVersion int 添加到 PK，其中最新版本的计算数字始终为 0。我可以做同样的事情并根据版本号计算它。这对性能有帮助吗？

  • 查询数据有一个额外的步骤，以确保您获得最新版本，但这可以在 SP 中处理。

  • 在这种情况下还有什么其他缺点。我错过了什么吗？？

4

3 回答 3

3

我以前在企业系统中看到过这种模式，但 IMO 并不成功。

  • 您在这里混合了两个不同的问题，即实时数据和审计数据的存储。对这个表的查询总是需要记住他们是在寻找叶子数据还是审计数据（例如报告）——新的团队成员可能会觉得这不直观。您可能需要用视图等封装这种复杂性。
  • 正如您所提到的，性能将始终是一个问题。插入新记录还需要更新以前的记录以将其标记为不活动。您可能还需要考虑更改聚集索引以将所有版本保持在同一页面上。
  • 此表的外键将有问题。您是否引用了确切的版本记录？然后您是否修复了外键以指向新的实时叶子记录？

我能想到的这样做的一个好处是审计表 DDL 将始终与实时表同步 - 通常对实时表进行 2 表策略更改，并且审计和触发器 DDL 不会相应地更新。

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

于 2012-08-09T18:30:28.370 回答
2

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

您不想乱用监管要求。使用主键与版本以及触发器组合的复杂模式表明可能存在更简单的方法。

历史记录会影响当前记录的性能。如果您最终遇到每条记录都更改了 100 次的情况，那么将它们保存在同一个表中只会减慢查询速度。当然，您可以以对数据进行分区的形式着手处理更复杂的问题。最后，解决方案更简单：将无法更改的数据保留在另一个无法更改的表中。您不想仅仅因为积累了很多历史就必须升级硬件。

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

于 2012-08-09T18:10:09.450 回答
1

这是正确的。审计跟踪可以保留在内部报告/审计的应用程序中，但信息安全最佳实践要求将审计日志从生成它们的系统中提取到日志管理/SIEM 解决方案中。

于 2012-09-25T23:35:56.580 回答