我正在处理的项目要求对记录进行数字“签名”，然后进行任何修改将创建该行的新“版本”。出于监管原因，不能修改“已签名”记录，也不应经常修改新版本。过去，可以通过创建一个与主表具有相同架构的单独的日志记录表，并添加一些额外的列来跟踪谁对其进行修改以及何时对其进行修改来做到这一点。
但是，在将所有数据（包括不同版本）放入同一张表的SharePoint进行了一些工作之后，我想到了另一种方法，该方法找不到人们正在做的任何示例：我可以将行的新版本正确在同一表格中，并增加版本号。然后将版本号添加到PK。
优点：
实现很容易，只需创建一个“代替更新”触发器，该触发器执行插入操作而不是对行进行“签名”更新。我可以轻松地添加一个IsCurrentVersion列以在触发器中进行更新。
查询旧版本很容易，只需获取所有记录即可
我要让用户从列表中选择的ID。
触发器很不错，因为它保证了行签名后不能更新（出于监管和审计目的）。
对表的架构更改不必复制到镜像“日志记录”表。
缺点：
该表可能会更大一些，但是在大多数情况下，对记录进行“签名”后就不会更改。在当前的使用水平下，客户估计每年最多大约有100,000行。 SQL Server可以处理数亿行，因此这看起来还不错。
索引编制和性能可能是一个问题。 SharePoint将tp_CalculatedVersion int添加到PK，其中对于最新版本，计算出的数字始终为0。我可以做同样的事情，并根据版本号进行计算。这对性能有帮助吗？
查询数据还有一个额外的步骤，以确保您获取最新版本，但是可以在SP中进行处理。
在这种情况下还有哪些其他缺点。我错过了什么吗？
最佳答案
如果要求不更改签名数据，则应将其移至另一个表。实际上，我可能建议将其移动到另一个数据库/架构，在该数据库/架构上，表上唯一允许的操作是插入和读取记录。如果确实要阻止更新，则可以同时使用权限和触发器。
您不想搞乱法规要求。使用主键和版本以及触发器的组合的复杂模式表明可能存在更简单的方法。
历史记录会影响当前记录的性能。如果最终导致每条记录更改了100次，那么将它们保存在同一表中只会降低查询速度。当然，您可以通过对数据进行分区的形式来承担更多的复杂性。最后，解决方案更加简单：将无法更改的数据保存在另一个无法更改的表中。您不希望仅由于积累了许多历史记录而升级硬件。
我还建议在历史记录中包含有效日期和结束日期。这样一来，您就可以重建特定日期的所有数据，这对用户将来可能会有用。
关于sql - 同一表中的SQL Server审核数据，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11889247/