我有一个小网店，你可以在那里预订旅行。 数据库中的每个行程都有有限的车票数量。 显然，如果车票==0，用户就不能预订特定的行程。 但是，这里是我关心的问题:如果我的脚本检查是否有足够的票证，并认为“是的，有足够的票证，现在执行查询”，该怎么办。 然而，与此同时，其他人会预订该行程，因此在检查是否有足够的票和预订过程之间，票的数量会发生变化，并且原始脚本最终会预订一个没有可用票的行程，而我的DB中最终会出现负值。
我知道这不太可能发生，因为我们谈论的是一个非常短暂的时间窗口。 我只有一个主意，在我看来是安全的:在更新行程之前，检查新的票额是否小于0。 我只是想听听另一种看法。 这样安全吗？
我有另一个想法，那就是在结账时预订票，但这似乎需要更多的工作来编程。
如果你的网站没有数百人同时预订，你可以不用锁表。
希望有帮助。 我已经在数周内为2K注册的系统使用了这种方法。
你所描述的并不安全。 数据库设计的一个主要目标是确保数据的逻辑完整性，即确保数据中永远不存在不合逻辑的条件。 拥有<0张票的余额永远不可能是合乎逻辑的。
有几种方法可以避免这个问题。 这些部分取决于您使用的数据库引擎。
您可以通过在quantity Reasting列上定义检查规则来稍微修改当前模型，以强制quantity must be>=0。 如果您这样做，任何会导致数量<0的事务都将被DB引擎拒绝。 您需要添加应用程序逻辑，以便在发生这种情况时做什么--向用户解释并撤消更大的购买事务中所需的任何其他操作。 这是一种生硬但有效的做法。
或者您可以更改标识每个票据的总体方法。 不是只说您还有5张票，而是跟踪每个票的状态，比如票ID 1，2，3，4和5。 就像一张机票或者一张特定座位的音乐会票，你需要识别每一张机票。 当用户开始购买事务时，您将用“正在购买”状态（或时间戳）标记特定票据，这将使它们对其他用户不可用。 用户必须在特定时间前完成交易，否则票据将返回到所有人可用的状态。 如果在查询中使用状态/时间戳，则不会出现新的竞争条件。
也有其他的方法，但这些应该会让你开始。
