sql - Web 应用程序应该使用显式 SQL 事务吗？

Question

考虑一个常规的 Web 应用程序，主要通过 SQL 数据库执行基于表单的 CRUD 操作。在这样的 Web 应用程序中是否应该有明确的事务管理？还是应该简单地使用自动提交模式？如果进行交易，“每个请求的交易”是否足够？

score 10 · Accepted Answer

我只会在你做的事情实际上是事务性的时候使用显式事务，例如，发出几个高度相关的 SQL 命令。我想这方面的经典例子是银行应用程序——从一个账户取款并将其存入另一个账户必须始终成批成功或失败，否则有人会被敲诈！

我们在 SO 上使用事务，但只是很少使用。我们的大多数数据库更新都是独立的和原子的。很少有人具有上述银行示例的属性。

score 2 · Accepted Answer

我强烈建议使用事务模式来保护数据完整性，因为自动提交模式会导致部分数据保存。

score 1 · Accepted Answer

这通常在数据库接口层为我处理 - Web 应用程序很少在事务中调用多个存储过程。它通常调用一个存储过程来管理整个事务，因此 Web 应用程序只需要担心它是否会失败。

通常，Web 应用程序不允许访问其他事物（表、视图、内部存储过程），如果在尝试之前未将它们包装在客户端在连接级别启动的事务中，这可能会使数据库处于无效状态到他们的电话。

在 Web 应用程序启动事务的情况下也有例外，但它们通常很少而且相差甚远。

score 0 · Accepted Answer

这取决于如何完成 CRUD 处理，当且仅当模型实例的所有创建和修改都在单个更新或插入查询中进行时，您才能使用自动提交。

如果您在多个查询模式下处理 CRUD（一个坏主意，IMO），那么您当然应该明确定义事务，因为这些查询肯定是“事务相关的”，您不希望在数据库中以半模型结束. 这是相关的，因为一些 Web 框架出于各种原因倾向于以“多重查询”的方式做事。

至于使用哪种事务模式，这取决于您在数据视图方面可以支持什么（即，当客户看到数据时需要多最新的数据）以及在性能方面您必须支持什么。

score 0 · Accepted Answer

您应该使用事务，因为不同的用户将同时访问数据库。我建议您不要使用自动提交。使用显式事务括号。至于每笔交易的解决方案，您应该将特定的工作单元括起来（无论这在您的上下文中意味着什么）。

您可能还想查看 SQL 数据库支持的不同事务隔离级别。他们将根据阅读用户看到的部分更新记录提供一系列行为。

score 0 · Accepted Answer

最好在单个存储过程中插入/更新到多个表中。这样，就无需从 Web 应用程序管理事务。

6 回答 6