不需要“一致状态”/“原子性”时的数据库事务

Question

如果我不需要一致的状态或“严格”原子性，我正在尝试了解何时使用数据库事务。

我没有一些银行风格要求需要减少一列以抵消其他地方的添加。

我确实有某种形式的原子性，但只是为了“易于使用”，我想知道这是否足以使用数据库事务。

具体来说，我要求我的用户在表 A、B 和 C 中创建一个条目。表 C 依赖于 B，B 依赖于 A。在浏览器上，我实际上以一种形式显示所有数据，当用户提交时，它被发送到后端尝试表 A 中的条目，然后是 B（使用刚从 A 创建的引用 Id），然后是 C（使用从 B 创建的引用 id）。

如果 A 失败，则向用户显示有关 A 的错误消息的表单。 如果 A 成功，但 B 失败，则将用户重定向到添加 B 和 C 的页面。 如果 A & B 成功而 C 失败，用户将被重定向到添加 C 的页面。

正如您所看到的，这可能会涉及大量错误处理，而仅显示“全部成功”或“失败，未创建任何内容”的事务将是最简单的，因为我可以让用户保持在同一页面上或者如果成功则重定向。还要记住，B & C 失败的可能性很低，因为我在客户端进行验证......

我的问题是，当我对原子性的需求不是那么“严格”时，我应该何时使用事务方法与错误处理方法。在选择事务方法或一系列插入方法之前，我需要考虑哪些因素。

Answer 1

您应该在“全有或全无”的情况下使用事务。 IOW，如果 B 或 C 失败，则应回滚到 A 的保存（插入或更新）。如果所有都没有通过，则没有通过，并且数据库保持在尝试之前的状态。也就是说，用某些语言进行交易可能很困难。在您的情况下，我可能更喜欢创建一个存储过程，将所有数据传递给该过程。在过程中，我会将操作包装在事务中，并让过程返回通过/失败指示符，或创建的表 A 中的记录 ID，如果任何部分失败，则返回 -1。