用于不同类型实体的可扩展批准工作流的系统设计

Question

我正在寻找一种有效的方法来创建草稿并启动域中某些实体的批准工作流程。用户应轻松跟踪更改并批准或拒绝更改。您能否建议一个通用的模型/方法/路线图来轻松提供这些功能？

假设我有这个模型：

    Declare @testVal as varchar(50)='ok'
select CASE WHEN IsNUMERIC(@testVal)=1 THEN Cast(@testVal as numeric) ELSE 'n' End

假设用户添加或更新或删除了一些CourierDistributionArea实体。您将如何存储这些实体的新的待审批版本？您将如何设计该系统以轻松添加要在此批准工作流程中使用的新型实体？您如何将变更集呈现给最终用户？

Answer 1

有很多选项，这些选项取决于用户可能做出的更改，多个用户是否可以同时提供替代草稿以及要使用的存储方式（我无知地假设一些基于表的RDBMS SQL Server）。

1。草稿表

在CarDraft表旁边创建一个Car表。目标表中的所有列都应显示在草稿表中，以及与草稿本身相关的元数据所需的任何其他列。草案获得批准后，将相关列上载到目标表中，然后删除该草案。

专业人士

• 无需在同一表格中支持同一实体的多个版本
• 草案不会以任何方式影响目标表上的OLTP

缺点

• 要维护的附加表

2。版本化实体

在目标表上创建Version和Published列，并放宽使用原始主键强制执行单行的约束，而不是允许多行，而只允许使用Published行列设置为true。

专业人士

• 没有其他要维护的表
• 无需写两次行（只需删除旧行并在单个事务中将Published位翻转到新行）

缺点

• 可能更复杂的约束/应用程序验证
• 在加入Published列时进行附加检查（容易忘记）

3。转型批准

同样，根据用户可以执行的修改实体的操作，您可以存储更改操作本身而不是将新状态存储为草稿。例如，它可以存储在CarModifications表中，可能作为部分JSON对象存储，也可以存储为数字或行，每行代表目标表中列的值更改。如果需要，可以将多行分组为一个OperationId。

专业人士

• 未更改目标表
• 可以将多个表的多个更改键入单个操作ID并应用于事务中

缺点

• 更复杂的建模
• 更复杂的验证