如何在审计表中进行批量更改？

Question

我有一个系统，必须审核业务对象的所有更改。因此，实体MyEntity具有Number属性，当您更改此字段时，系统会单独保留原始记录，并使用新的数字值创建另一条记录，并标记原始记录存档。 Number 不是主键。还有一个Version字段用于跟踪实体的每个版本，还有一个Id字段用于跟踪多个版本的对象标识。到现在为止还挺好。

如果您删除该实体，系统不会删除该记录，只会将其标记为已删除。到现在为止还挺好。

这是问题所在。现在客户端在列表中有一堆实体，可能存在差距：

Item 1
Item 2
Item 3
Item 5
Item 6
...
Item 10

他们希望能够做两件新事：

1. 插入数字为5的项目，并将所有后续项目向上移动一个数字（5 - > 6,6 - > 7等）
项目中的
2. 折叠差距，例如，重新编号5 - ＆gt; 4，并将所有后续项目向下移动一个数字。

这对我来说似乎非常讨厌，因为通常需要对一个数字进行任何更改，因此我不能像这样批量更改所有数字。 （而且它仍然更复杂，因为每个更改都需要得到主管的批准，并且更改可以恢复到以前的审核状态。）

更糟糕的是，第4项可能存在，但由于它处于存档状态而丢失。如果要折叠后续项目，现有的已归档项目会发生什么？在审核这些情况时，我无法看到合理的方法来处理这些情况，并允许批准和恢复。任何人都知道如何处理这个？

Answer 1

  

我有一个系统，其中必须对业务对象进行所有更改   审计。

尝试为 Number 属性建议此规则的例外。如果此属性也被用于其他原因并且必须进行审计，那么您可以建议一个新字段 OrderByNumber 并使其免于审计要求。

如果你的论点面临阻力，我会尝试将Number或OrderByNumber重命名为荒谬但显而易见的东西。它会让人微笑，他们会看到重点： NotABusinessConcernNumberButUIElementNumberUsedForVisualOrdering 。

如果您无法审核业务对象的规则，则必须创建不同的UI /表示对象层，并在两者之间保持映射。

Answer 2

我从未真正以令人满意的方式解决这个问题，但是我们通过实现一种特殊模式来处理这个问题，该模式仅适用于超级管理员，其中审核被禁用以进行此类身份更改操作，理由是{ {1}}虽然不是主键，但它是一个必不可少的用户键，如果你更改它，你就会将对象标识更改为一个新的东西，它以一个干净的平板开始。不理想，但是合理的妥协。