在存储过程或应用程序中处理事务的最佳位置在哪里？

Posted 2023-03-27

【中文标题】在存储过程或应用程序中处理事务的最佳位置在哪里？

【英文标题】：Where is the best place to handle transactions in stored procedure or in application?

【发布时间】：2009-04-03 21:18:54

【问题描述】：

当我的 C#.net 应用程序更新多个表中的记录时，我会使用事务，因此如果在事务期间发生任何故障，我可以回滚。

哪个是更好的做法？

-使用带有BEGIN TRANSACTION/ROLLBACK/COMMIT TRANSACTION的存储过程； - 在应用程序中使用 TransactionScope，如下所示：

using (TransactionScope ts = new TransactionScope())

【参考方案1】：

这不是业务逻辑问题，而是数据完整性问题，我觉得在存储过程中可以这样做。我喜欢让事务逻辑尽可能接近操作，以缩短它们的持续时间。

【讨论】：

他说他的应用更新了不止一张表中的记录。这意味着他要么需要在一个 proc 中打开 tran 并在另一个中提交，要么他需要在一个 proc 中拥有所有逻辑（或在多个 proc 中相互调用），这绝不是一件好事......

没错，数据库事务应该尽快结束。相反的从来都不是一件好事。

您可以跨多个表、多个数据库甚至服务器打开一个事务。就像 Mufaka 所说，最好让 sql server 处理它自己的事务，否则您可能会遇到严重的数据完整性问题。我认为实际上是交易的重点。

【参考方案2】：

TransactionScope 是一种在代码中管理事务的非常好的方法。它允许您跨多个方法嵌套事务代码，并在必要时自动扩展到分布式模式。

我更喜欢使用 TransactionScope 而不是存储的 proc 事务，因为它可以让您对代码进行更多控制。

【参考方案3】：

或者你可以在这两种情况下都这样做。查看链接：http://www.4guysfromrolla.com/webtech/080305-1.shtml

【参考方案4】：

如果您的事务要转到一个数据库，最好在存储过程中进行事务。另一种方式可能仅由逻辑问题引起（DBA 不喜欢您，或者他正在休假）。 如果您在一个事务中调用不同的事务源（SQL Server 和 Oracle） - 除了在代码中执行事务之外别无选择。

【参考方案5】：

我强烈建议为页面设置一个过程并在那里管理所有 sql 操作。如果页面上有多个需要执行的任务需要多个过程，则只需让一个过程管理其他过程。如果需要，您的过程始终可以返回多个记录集。

您的页面会执行得更快 - 不会 大量数据来回传输， 只需一拉。 sql 上的所有代码都已经编译了执行计划。 您将能够 更多地处理你的错误 有效 - 在一个地方，而不是 在两个地方 - 有两个 单独的系统来决定它是否 足以失败 - 通过任何 错误来回维护 您的数据完整性。 您可以最大限度地减少故障点。 如果交易进展顺利，但 Web服务器打嗝，sql 服务器正在等待 回复。 您将节省大量的故障排除和调试时间。 它将帮助您在 sql server 上模块化您的代码。您可以重用存储过程来执行类似的任务，并最终得到一个更灵活、可扩展的健壮系统。 HTH

【参考方案6】：

以下是我关于何时使用交易的 2 条简单规则：

如果过程有多个数据更改语句，它将包含一个事务。 如果应用程序调用多个存储过程来更改数据，它将包含一个事务。