什么是金融运作中的锁定、僵局问题？
质疑 SQL - 何时应该使用“with (nolock)”
在一家当地金融机构，我因向他们表达了我的观点（他们的程序员的痴迷）而被他们的程序员斥责（b）他们的 MS SQL Server 2005 数据库中的锁定问题对我来说没有多大意义。
如果财务操作从未更新、删除，甚至不正确的操作（“交易”的一部分？）通过在数据库中插入（添加）新的更正记录来纠正，可能会出现哪些锁定、阻塞、死锁的问题？
这个用英语怎么说？在其他语言中，它被称为 storno、stornoed（？）操作/记录。
因此，据我了解，“交易”实际上永远不会回滚，并且永远不会有不正确/不存在的记录，只有未实现的记录。
更新：
我在 google 上搜索 storno，但找不到任何其英文定义或其在英文文本中的使用的结果。
我仅在意大利语中找到了 storno（拉丁字母）的定义。
但会计是在意大利发明的，许多意大利语会计术语也用于其他语言，例如俄语会计（银行业）。
我还认为这是国际上公认的财务运营会计惯例，不是吗？
更新2：
S.Lott 给了我的链接事务在 ERP 应用程序中被撤销是一件大事！ 告诉 storn 是撤销事务。
嗯，这是不正确的。 Storno 不仅仅是交易，它是纠正错误操作的任何操作（交易的一部分），尽管 2 个操作组合起来可能看起来会逆转交易（由 2 个操作组成 - 对目标和源帐户进行贷记和借记）。
那么，storno不是世界上常见的财务会计实践吗？
无论如何，我想避免讨论会计细节/技术/术语，并将问题限制在记录从未被删除或更新的上下文中。
锁定、阻塞、死锁、在这种情况下的表现？
Subquestioning SQL - when should you use “with (nolock)”
In one local financial institution I was rebuked by their programmers for expressing them my opinion that (their programmers' obsession with) (b)locking issues in their MS SQL Server 2005 database(s) did not make much sense to me.
What are the possible issues with possible locking, blocking, deadlocking if financial operations are never updated, deleted and even incorrect operations (part of "transactions"?) are corrected by inserting (adding) new correcting records into database(s)?
What is the term for this in English? In other languages it is called storno, stornoed (?) operations/records.
So, as I understand, the "transactions" are really never rolled back and there are never incorrect/non-existent records, only non-actualized ones.
Update:
I googled for storno and could not find any results with its definition in English or its use in English texts.
I found definition for storno (in latin letters) only in Italian.
But accounting was invented in Italia and many Italian accounting terms are used in other languages, for ex., in Russian accountance (banking).
I also thought that it was internationally accepted practice in financial operations accountance, isn't it?
Update2:
S.Lott gave me link to The way that transactions are reversed in an ERP application is a big deal! telling that storn is reversal transaction.
Well, this is not correct. Storno is not only transation, it is any operation (part of transaction) correcting incorrect operation though 2 operations combined might seem to reverse tranaction (consisting of 2 operations - of crediting and debiting on target and source accounts).
So, storno is not common financial accountancy practice through the world?
Anyway, I'd like to avoid discussion of accountancy details/techniques/terms and to restrict the question to context when records are never deleted or updated.
What are the possible problems with locking, blocking, deadlocking, performance in this context?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“Storno 交易”或“逆转交易”总结得很好。在很多地方。
http://richardatopenbravo.blogspot.com/2010 /02/way-that-transactions-are-reversed-in.html
http://help.sap.com/saphelp_46b/helpdata/en/d2/6f921f415e11d182b10000e829fbfe/content.htm
http://forum.wordreference.com/showthread.php?t=1875166
不要将软件实现与会计混为一谈。合理的实现可以用最少的锁定来实现。然而，这并不意味着什么。您可能会受到谴责，因为该软件 (a) 设计不佳，并且 (b) 由于设计不佳而需要仔细锁定。
由于我们不知道软件编写得有多好或多差，所以无法猜测。他们可能知道一些你不知道的关于他们的系统的信息。
一个简单的 storno 交易系统应该很容易实现。事实上，它应该是微不足道的。
如果在插入期间使用页级锁定，一对“仅插入”表仍然可能遇到死锁。
表 A，第 1 页在事务 X 中具有插入。
表 B，第 2 页
在事务 Y 中具有插入。表 B，第 2 页在事务 X 中具有插入。
表 A，第 1 页在事务 Y 中具有插入
。避免死锁的方法是让整个系统使用单个表。或者将所有事务限制在单个表中。或者使用单个数据库范围的锁。
如果您有多个表操作（和页级锁定），那么即使使用仅插入操作，您仍然会遇到潜在的死锁。显然这种情况很少见，但仍然有可能。
"Storno Transactions" or "Reversing Transactions" are summarized nicely. In lots of places.
http://richardatopenbravo.blogspot.com/2010/02/way-that-transactions-are-reversed-in.html
http://help.sap.com/saphelp_46b/helpdata/en/d2/6f921f415e11d182b10000e829fbfe/content.htm
http://forum.wordreference.com/showthread.php?t=1875166
Don't conflate software implementation with accounting. A reasonable implementation can get by with minimal locking. That doesn't mean anything, however. You may have earned a rebuke because the software is (a) badly designed and (b) requires careful locking because of poor design.
Since we don't know how well or how poorly the software is written, it's impossible to guess. They may know something about their system that you didn't know.
A simple storno transaction system should be easy to implement. Indeed, it should be trivial.
A pair of "insert-only" tables can still encounter deadlocks if page-level locking is used during the inserts.
Table A, page 1 has an insert in transaction X.
Table B, page 2 has an insert in transaction Y.
Table B, page 2 has an insert in transaction X.
Table A, page 1 has an insert in transaction Y.
The only way to avoid deadlocks is to have the entire system use a single table. Or have all transactions limited to a single table. Or use a single database-wide lock.
If you have multiple-table operations (and page-level locking) then you will still have potential deadlocks even with insert-only operations. Clearly it's rare, but still possible.