Database 提交更改后撤消的设计模式

我们可以撤销动作命令或记忆模式

如果我们正在使用卡夫卡，那么我们可以以相反的顺序重放流，以返回到以前的状态

例如，Google docs/sheet等也有版本历史记录

对于pcpartpicker，它如下所示：

为了安全起见，我想承诺所有事情，但如果需要，我想回到以前的状态

我知道我们可以禁用自动提交并使用事务控制语言（提交、回滚、保存点）。但我说的是，即使在我做出改变之后，也要放弃

---

我该怎么做呢？

这个问题没有一个真正的通用答案。这一切都取决于数据库的结构、跨实体事务的范围、分布式事务、在恢复更改之前允许经过多少时间/事务等

纪念图案

Memento模式是一种可能的方法，但由于关系数据库的性质，需要对其进行修改，如下所示：

您需要有
事务日志
表/列表，其中包含受事务影响的实体和属性（表和列）的信息及其主键、新旧值（事务发生前的值和事务发生后的值）以及日期时间戳。这与
命令
（
memento
）模式相同
接下来，您需要一种机制来识别由数据库中的存储过程作为事务的结果触发的非显式更新。这一点很重要，因为表中的更改可能会触发其他表中的更改，而这些更改不是由
命令
显式捕获的
回滚机制需要通过在相同实体上构建后续事务列表来确定事务是否符合回滚条件，并确定此事务是否符合回滚条件，或者在回滚此事务之前，还需要回滚某些后续事务
如果在较长时间后允许回滚，或数据的
近实时消耗
时，还应该有一个
事务观察者列表
，这些进程需要被告知事务不再有效，因为它们已经读取了新数据并根据新数据做出了决定。例如，生成累积报告的流程。当事务回滚时，回滚将使报表无效，因此需要再次生成报表
对于主要用于分布式事务的短期回滚，您可以检查，并将其作为构建解决方案的起点

历史记录表
另一种方法是保持
增量更新
或也称为
历史记录表
。其中，行的每次更新都将是具有新版本的历史记录表中的一个插入。与前一种情况类似，当您尝试回滚已提交的事务时，您需要决定可以在历史记录中追溯到多远

监管问题
最后，在处理业务数据时，如
发票
、
库存
等，您还需要检查与取消已提交交易相关的规定。例如，在会计系统中，不允许删除数据，而是添加一个包含薪酬的新行（例如，从发货清单中删除产品不会删除产品，而是添加一行
-quantity
，以取消原始行的影响，同时保持对更改的审核跟踪。
必须将零件清单保存在历史文件中。若要撤消，请读取历史文件并撤消数据库更改。对于零件清单，请至少意味着将项目重新添加到库存中，并关闭未完成的列表。