释放数据库中库存的最佳实践

Question

我正在构建一个售票应用程序，用于跟踪门票库存，并在特定门票售完时停用它们。

我想知道当订单中途放弃时将库存释放回商店的最佳做法是什么。

当前流程：

• 用户将 items 添加到 order 中作为 line_items，并且 order 在成功付款后标记为已完成
• items 有一个 quantity_available，它是根据其 line_items 更新的，
• 我定期扫描 orders 中没有任何操作的 orders 20 分钟，删除这些订单的 line_item 并更新 quantity_available

感觉我错过了一些东西。其一，我失去了详细审查放弃订单的能力（我仍然有任何付款/拒绝等......但没有行项目）。如果用户在 21 分钟后尝试恢复旧订单，他们将不得不重新开始。

相反，它会占用库存 20 分钟，当一场演出几乎售完时，这可能会导致我们的销售损失。

任何见解将不胜感激。谢谢。

Answer 1

引入一个不同的标签怎么样：保留什么的。在处理订单时，您可以将票标记为保留，这会减少总库存数。但您现在确切地知道有多少张票处于待定状态。

在 20 分钟的长订单期间，如果现有商品数量非常少或已空，您可以向用户发送更新。 “订单已经停滞了5分钟。门票销售进展很快，请尽快完成订单，以确保您的门票仍然可用。”

您还可以告诉潜在买家，可能有 x 数量的预订门票可供使用，因此他们应该回来查看或进行其他操作。也许他们可以注册，以便在保留的票返回到系统时接收电子邮件。

Answer 2

我想知道为什么你们会根据未处理的订单占用库存？我正在考虑新蛋网和亚马逊等热门网站的运作方式。我可以创建一个购物车，并且它会无限期地存在。但它对我的库存没有任何作用，它只是数据库中的一条记录。有了 Newegg，我可以在几个月后返回该网站，而我废弃的购物车仍然在那里（这在过去对我来说非常方便）。

您仅在用户完成订单时修改库存。这还允许您运行有关废弃购物车的报告，因为您只需使用上次修改日期与订单完成情况相结合即可确定哪些购物车被废弃。

Answer 3

如果我理解正确的话，听起来您应该将不同的步骤封装到一个事务中，如果没有及时完成（即您提到的 20 分钟），该事务将回滚或暂停。这样您就可以锁定和解锁 line_items 记录，而无需来回添加它们。

听起来您还需要考虑如何定义“订单”。您可能需要引入更多步骤。办理订单的过程是“预订”，只有付款才算确认。这样您就可以将库存释放到“保留”（超过保留是可以的），并且第一个付款的人会收到订单。其他人失败了——他们应该更快！