我在asp.net中编写了一个非常简单的"电子商务应用"，是否需要在存储过程中使用交易？

读/写比约为9：1

解决方案

回答

很多人问我需要交易吗？我为什么需要它们？什么时候使用它们？

答案很简单：一直使用它们，除非我们有很好的理由不这样做(例如，不要将原子事务用于企业之间的"长期活动")。默认值应始终为"是"。我们有疑问吗？使用交易。

为什么交易有益？它们可以处理崩溃，故障，数据一致性，错误处理，可以编写更简单的代码等。随着时间的流逝，收益的清单将不断增长。

这是来自http://blogs.msdn.com/florinlazar/的更多信息

回答

答案是，这取决于。我们并不总是需要交易安全。有时候，这太过分了。有时候不是。

我可以看到，例如，当我们实现结帐流程时，只希望在收集所有数据后就将其完成等。考虑一下付款，我们可以回滚，这是我们需要交易时的一个示例。或者，也许在明智的情况下使用它们。

创建新的用户帐户时需要交易吗？也许，如果它跨越10个表(出于某种原因)，那么，如果它只是一个表，那么可能就不会。

这也取决于我们出售客户的方式以及客户的身份，以及客户的要求等等。但是，如果决定取决于我们，那么我会说，明智地选择。

我的底线是，避免过早的优化。生成应用程序时，请记住，我们可能需要返回并稍后在需要时进行重构/优化。看几个开源项目，看看他们如何实现应用程序的不同部分，并从中学到东西。我们会看到它们中的大多数根本不使用交易，但是有大量使用它们的在线商店。

回答

当然，要视情况而定。

它取决于特定存储过程执行的工作，可能与我们建议的"读/写比率"无关。通常，如果该工作单元的查询可能会受到其他同时运行的查询的影响，则应考虑将其包含在事务中。如果听起来不确定，那就是。通常很难预测在什么情况下某个特定的工作单元可以胜任该工作。

一个好的开始是回顾在工作单元(在这种情况下，在存储过程中)中正在执行的精确CRUD，并确定a)是否可能受到其他同时进行的操作的影响，以及b)其他工作是否重要直到完成这项工作的最终结果(反之亦然)。如果对这两个答案都为"是"，则考虑将工作单元包装在事务中。

这表明我们不能总是简单地决定使用还是不使用事务，而是应该在有意义的情况下应用它们。使用ACID定义的属性(原子性，一致性，隔离性和耐用性)可以帮助确定何时是这种情况。

需要考虑的另一件事是，在某些情况下，特别是如果系统必须快速连续执行许多操作(例如，大容量事务处理应用程序)，则可能需要权衡事务的相对性能成本。根据工作单元的大小，事务的提交(或者回滚)可能会占用大量资源，可能会对系统的性能产生不必要的负面影响，或者至少带来有限的收益。

不幸的是，要准确地回答这个问题并不容易："要视情况而定"。

回答

请记住，默认情况下，在SQL Server中，所有单语句CRUD操作都在隐式事务中。如果我们需要使多个语句充当一个原子单元，则只需打开显式事务(BEGIN TRAN)。

回答

在以下情况下使用它们：

• 我们可能需要测试并捕获一些错误，这些错误通常是从事务中进行并进行工作(查找事物，测试值等)，而这些错误通常是从事务中进行的，因此我们可以滚动支持整个操作。
• 存在任何类型的多步骤操作，如果它们失败，则在逻辑上应将它们作为一组回滚。