在存储过程或应用程序中,哪个地方是处理事务的最佳位置?

8

当我的C#.net应用程序在多个表中更新记录时,我使用事务,以便在事务期间发生任何错误时可以回滚。

哪种做法更好?

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


    using (TransactionScope ts = new TransactionScope())
    {
    }

6个回答

4

这不是一个业务逻辑问题,而是一个数据完整性问题,我认为在存储过程中处理这个问题是可以的。我喜欢尽可能将事务逻辑靠近操作以缩短它们的持续时间。


他说他的应用程序更新多个表中的记录。这意味着他需要在一个过程中打开事务并在另一个过程中提交,或者他需要将所有逻辑放在一个过程中(或在相互调用的多个过程中),这从来不是一个好的选择... - Andriy Volkov
真实的情况是,数据库事务应该尽快结束。相反的做法从来都不是一个好主意。 - Constantin
您可以在多个表、多个数据库甚至多个服务器之间打开一个事务。正如Mufaka所说,最好让SQL服务器处理自己的事务,否则您可能会遇到严重的数据完整性问题。这就是事务存在的实际意义。 - Praesagus

3

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

我更喜欢使用TransactionScope而不是存储过程事务,因为它在代码中给了您更多的控制权。



1
如果您的交易只涉及一个数据库,那么最好在存储过程中进行事务处理。其他方式可能只是由于后勤问题(DBA不喜欢您或他正在度假)。 如果您在一个事务中调用不同的事务源(SQL Server和Oracle),那么除了在代码中进行事务处理之外别无选择。

1

我强烈建议在页面上设置一个过程来管理所有的SQL操作。如果有多个需要执行多个过程的任务,只需让一个过程管理其他过程即可。您的过程始终可以返回多个记录集(如有需要)。

  • 您的页面将更快地执行 - 不会出现大量数据来回传输,只需一次获取即可。所有SQL上的代码都已经编译并具有执行计划。
  • 您将能够更有效地处理错误 - 只需在一个地方而不是两个地方处理错误 - 有两个独立的系统来决定是否足够重要而导致任何错误来回传递以维护数据完整性。
  • 最小化故障点。如果交易进展顺利,但Web服务器发生故障,则SQL服务器将等待响应。
  • 您将节省大量时间进行故障排除和调试。
  • 它将有助于模块化您在SQL服务器上的代码。您可以重复使用存储过程来执行类似的任务,并获得更灵活、可扩展、强大的系统。
  • HTH

1

以下是我使用事务的两个简单规则:

  • 如果存储过程包含多个数据更改语句,则应该使用事务。
  • 如果应用程序调用了多个更改数据的存储过程,则应该使用事务。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接