我应该在存储过程级别还是在中间层级别使用我的事务？答案

【问题标题】：Should I use my transactions on the stored procedure level or on the middle tier level?我应该在存储过程级别还是在中间层级别使用我的事务？
【发布时间】：2011-03-25 05:52:50
【问题描述】：

我们在我工作的地方使用内部 ORM，在很多情况下，我们需要在一次事务中做许多不同的事情。通常情况下，我会在整个事情的中间层包装一个事务，如果一切都好的话，就会成功。

我们的 ORM 中的另一个选项是构建它只是调用的自定义存储过程。我想知道 - 如果我只是创建一个自定义存储过程并围绕它进行 SQL 事务处理会更快吗？

那不是更快吗？如果是这样，为什么大多数人选择ORM路线？我的意思是，让您的数据库对象出现在对象模型中会使事情变得非常简单，就像它出现在智能感知中一样，但这就是您为了易用性而放弃性能的唯一原因吗？

【问题讨论】：

标签： sql performance stored-procedures orm transactions

【解决方案1】：

由于数据库软件可以对已知查询进行优化，因此存储过程可为您带来额外的性能优势。当您使用即席查询时，您将失去此优势。

我不知道您的特定系统，所以我不确定哪种系统适合您。对于我们来说，我们发现将尽可能多的逻辑推送到 DB 层上的存储过程中允许我们使用视图和存储过程创建业务逻辑层。这极大地简化了编码工作，并且始终一致地处理数据。

【讨论】：

真的吗？看到我总是被告知在 SP 中拥有业务逻辑是“不好的做法”，但我从未被告知为什么会这样
您是否尝试过扩展一个在数据库中具有所有逻辑的系统。它几乎总是失败。俗话说“硬件比程序员便宜”。
不是所有的逻辑，那就是用铲子敲钉子。但是我们案例中的大部分逻辑都很好地放置在数据库中。您的里程可能会有所不同。

【解决方案2】：

我觉得业务事务和数据库事务应该分开处理。我使用数据库来执行 CRUDS，并根据需要将事务管理应用于这些特定功能。在中间层你也可以应用事务管理，但在业务场景中并处理在数据库中抛出的错误来控制流。

例如，如果数据库中的插入失败，则会引发错误并在中间层进行处理。从那里它可以捕获 DB 异常并执行适当的步骤来回滚其他对象。

我觉得这有助于将业务逻辑保留在其所属的位置，并远离数据层。保留此逻辑可让您的数据层具有可移植性。

【讨论】：

是的，我通常也会这样做。但是，虽然它更整洁，但执行起来不是比将所有业务逻辑都放在 SP 中要慢得多吗？
可能，从某种意义上说，您需要单独调用 DB 来回滚第一项，而不是回滚两个数据事务。但是，我觉得在 DB 中放入逻辑往往是逐条记录的分析和迭代，这与大多数 DBMS 擅长的恰恰相反。