问什么时候交易会成为一种负担而不是一种好处？

EN

我认为任何设计模式本身都不能解决这个问题。良好的数据库设计，良好的存储过程编程，特别是学习如何保持事务短，将缓解大多数问题。但是，没有100%保证没有问题的方法。

基本上，在我职业生涯中看到的每一种情况下，死锁和减速都是通过修复存储过程来解决的：

• 确保访问所有表以防止死锁
• 修正索引和统计数据会使所有事情都更快(从而减少死锁的可能性)
• 有时候根本不需要交易，只是“看上去”而已。
• 有时，事务可以通过在单个语句中创建多个语句存储过程来消除。

从长远来看，共享资源的使用是错误的。因为通过重用现有的环境，您正在创造越来越多的可能性。只需回顾一下繁忙的海狸:) Erlang的方式是产生容错和易于验证的系统的正确方法。

但是，对于许多广泛使用的应用程序来说，事务性内存是必不可少的。例如，如果你咨询一家银行的数百万客户，你就不能为了效率而复制数据。

我认为monads是一个很酷的概念来处理改变状态这一困难的概念。

如果您在这里谈论的是“云计算”，答案将是将每个事务定位到云中发生的位置。

不需要整个云保持一致，因为这会降低性能(正如您所注意到的)。简单地说，跟踪更改的内容和位置，并在更改在系统中传播时处理多个小事务。

在云的另一端，用户A更新记录R和用户B的情况(尚未)与用户A在当前严格事务环境中尚未进行更改时的情况相同。这可能会导致更新密集型系统中的差异，因此系统的体系结构应该尽可能少地使用更新--将事物移动到数据的聚合，并在精确的图形关键时提取聚合(即从写入时间到临界读取时间的一致性要求)。

只是我的战俘。在这种情况下，很难设想一个与应用无关的系统。