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

Question

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

Answer 1

我只会在您执行实际上是事务性的事务时使用显式事务，例如，发出几个高度相关的SQL命令。我想这个典型的例子就是银行应用程序 - 从一个帐户中提取资金并将其存入另一个帐户必须始终成功或失败，否则有人会被扯掉！

我们在SO上使用交易，但只是谨慎使用。我们的大多数数据库更新都是独立的和原子的。很少有上面银行业例子的属性。

Answer 2

我强烈建议使用事务模式来保证数据的完整性，因为自动提交模式可以节省部分数据。

Answer 3

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

通常，Web应用程序不允许访问其他内容（表，视图，内部存储过程），这些内容可能允许数据库处于无效状态（如果尝试这些状态而不包含在连接级别启动的事务中）客户来电之前。

有一些例外，其中一个事务是由Web应用程序启动的，但它们通常很少见。

Answer 4

您应该使用不同用户同时访问数据库的事务。我建议你不使用autocommit。使用显式事务括号。至于每笔交易的解决方案，你应该把一个特定的工作单元括在一起（无论你在上下文中是什么意思）。

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

Answer 5

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

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

至于使用哪种交易模式取决于您在数据视图方面可以支持的内容（即客户看到数据时的当前状态）以及您在性能方面必须支持的内容。

Answer 6

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