在数据库中发布库存的最佳实践

时间:2011-02-25 18:13:09

标签: database-design ticket-system inventory

我正在建立一个销售门票的应用程序,该应用程序跟踪门票的库存,当特定门票售罄时将其取消激活。

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

目前的流程:

  • 用户将items添加到order line_itemsorder在成功付款后标记为已完成
  • itemsquantity_available根据line_items
  • 更新
  • 我定期扫描orders,而不是> 20分钟后,删除这些订单“line_item并更新quantity_available

感觉我错过了这个。首先,我失去了详细审查废弃订单的能力(我仍然有任何付款/拒绝等等......但没有订单项)。如果用户在21分钟后尝试恢复旧订单,他们将不得不重新开始。

相反,它会将库存占用20分钟,这可能会导致我们的销售额几乎售罄。

非常感谢任何见解。感谢。

3 个答案:

答案 0 :(得分:6)

如何引入不同的标签:保留或其他东西。在处理订单时,您可以标记保留的票据,这会减少总库存数。但是你现在确切地知道有多少门票处于不确定状态。

在20分钟的长期订单中,如果现有物品的数量非常低或为空,您可以向用户发送更新。 “订单停滞了5分钟。售票速度很快,请尽快完成订单,以确保您的机票仍然可用。”

您还可以告诉潜在买家有可用的x个预订门票,因此他们应该回来查看。如果预订的机票重新进入系统,他们可能会注册接收电子邮件。

答案 1 :(得分:0)

我想知道你为什么要根据未经处理的订单捆绑库存?我在考虑Newegg和亚马逊等热门网站的运作方式。我可以创建一个购物车,它将无限期地生活。但它对我的库存没有任何作用,它只是数据库中的记录。有了Newegg,我可以在几个月后回到现场,我的废弃购物车仍在那里(过去对我来说非常方便)。

您只需在用户完成订单时修改广告资源。这还允许您运行有关废弃购物车的报告,因为您只需使用上次修改日期并结合订单完成来识别哪些购物车被放弃。

答案 2 :(得分:0)

如果我理解这一点,听起来你应该将不同的步骤封装到一个回滚或暂停的交易中,如果没有及时完成 - 即你提到的20分钟。这样你就可以锁定和解锁line_items记录而无需来回添加它们。

听起来您还需要考虑如何定义“订单”。您可能需要引入更多步骤。完成订单的过程是“保留”,只有付款确认后才会“保留”。通过这种方式,您可以将库存发放到“预订”(预订可以)并且第一个付款的人获得订单。其他人失败了 - 他们应该更快!