如何解决销售数据库中的并发事务问题

Question

我的应用程序是将一些数据存储在名为Transactions的SQL表中。 用户可以从Client1到Client2销售一些东西，然后Client2就可以销售。 我将它以下列方式存储在表中：

Client 1 | Buy  | Something | Price  | External |
Client 1 | Sell | Something | Price2 | Client 2 |
Client 2 | Buy  | Something | Price2 | Client 1 |

第一个Client1买了它（把它带进来或者只是让它完全重要）。 然后他把它卖给另一个客户。

一切都很好，它可以工作，但我的应用程序有一个很短的时间，它不检查客户端1是否仍然具有它声称拥有的内容（当数据加载到gui时）。 因此，如果有2个用户可以运行它，那么Client1的产品可能会被多次出售。 最有可能它不会发生，因为我的用户倾向于分享他们正在做的事情的工作，但总是但......

怎么预防这个？ 在插入事务就足够之前进行简单的选择查询检查还是应该以不同的方式完成？ （我可以想象多个人为此奔跑而有些人会成功的情况）。 在重型系统的实际情况下如何处理？ 就像当你从两个不同的CashMachines的2张牌中从一个银行账户中选择钱时（虽然我相信他们只会让平衡在这种情况下低于0，即使不允许）。

那么我有什么选择？ 你对此有什么看法？

Answer 1

我认为这不是一个真正的库存跟踪系统，数据库只是记录现实世界的事件，而是一些虚拟拍卖或市场类应用，其中“现实”是应用程序认为的任何东西。

如果你只记录历史，你将永远不会拥有当前状态。 没有当前状态，你无法做出有效的正确性决定。 所以保持现状。 有一个项目表和他们当前的所有者。 那么你问的问题就变成了“如何防止丢失更新？”的简单问题。 或'我如何防止盲写'？ （即写 - 写冲突），答案在数据库应用程序中是众所周知的：使用乐观并发控制。

有关如何在C＃和SQL中使用Optimistic Concurrency的详细讨论，请参阅乐观并发（ADO.NET） 。

Answer 2

我计算运行总计，将它们存储在同一行，并使用约束来确保运行总计是非负数。 这里描述： 非规范化以强制执行业务规则：运行总计