为什么在客户完成下订单之前生成订单数据库记录？
我正在使用一个订购系统，并试图首先理解为什么它是这样设计的。
我无法理解的一件事是，为什么系统甚至在客户下订单之前就为潜在客户创建了唯一的订单记录。
因此，所发生的情况是订单输入并选择他们想要购买的商品，然后在显示下订单按钮之前，已经为潜在保存了订单记录> 客户。
其影响 - 这是令我困扰的 - 系统中有数千个废弃订单，其中用户从未点击过最终放置您的订单order 按钮来完成销售。
订单记录不应该仅在用户点击“下订单”后才生成吗？为什么要这样做？
I'm working with an ordering system and trying to understand first of all why it was designed the way it was.
One of the things I can't understand is why the system creates a unique Order record for a potential customer even before the customer places the order.
So, what happens is the order goes in and chooses what they want to buy and then, before the Place your order button is displayed, an order record is already saved for the potential customer.
The effect of this - which is what is bothering me - is that there are thousands of abandoned orders in the system where the user never clicked on the final Place your order button to finalize the sale.
Shouldn't the order record be generated only after the user clicks "Place your order"? Why do it otherwise?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从您所说的来看，应用程序提供了非常有用的功能。它会记住用户选择的所有内容，因此他可以关闭页面，检查其他商店，再考虑一下，返回您的网站并查看为他保存的订单。
另外，数据库中增加一万行将花费您一分钱，所以我认为没有理由担心它。如果出现问题，您可以定期清理它们，例如，如果用户一个月没有出现。
Judging from what you said, application provides very useful functionality. It remembers everything user selected, so he can close the page, check other outlets, think some more, get back to your site and see his order saved for him.
Also, ten thousands additional rows in database will cost you a penny, so I see no reason to worry about it. And if it turns into a problem, you can routinely clean them up, e.g. if user doesn't show up for a month.
Francis，造成这种情况的原因有很多，首先是分析，虽然还有其他方法可以实现这一点，但这是了解 (a) 订单是否被放弃以及 (b) 在流程中的哪个点被放弃的好方法。这也有利于让用户在 2 天后回来并“结帐”:)
Francis, there are a lot of reasons for this the first and formost being analytics and while there are other ways to achieve this, it is a good way to know (a) was the order abandoned and (b) at what point in the process. It is also good for letting the user come back and "checkout" 2 days later :)
该系统是否以一般电子商务方式运行，具有单独的“购物篮”和“订单”实体？或者它是通过在用户将商品添加到订单中时简单地构建一个订单实体然后最终确定来工作的吗？
如果是后一种情况，正如已经提到的，它可能按照您描述的方式工作，作为存储正在进行的订单的方法。但如果是前一种情况（有一个单独的篮子），那么你就对了，这有点奇怪，而且似乎没有必要。
通常从头开始设计的专用电子商务系统将“购物篮”（正在进行的工作）与“订单”（成品）的概念分开。但您确实会发现许多系统可能随着时间的推移而演变，并且最初设计时可能并未考虑到电子商务，因此您会发现流程有点混乱且不太理想。
Does the system work in the general ecommerce fashion with seperate "basket" and "order" entities? Or does it work by simply building up an order entity as the user add items to their order and then finalises that?
If the latter scenario then, as already mentioned, it probably works in the way you describe as a means of storing an order in progress. But if it's the former scenario (with a separate basket), then you're right in thats it a little odd and does seem unnecessary.
Usually dedicated ecommerce systems designed from the ground up, separate out the concepts of "basket" (a work in progress) from "order" (the finished product). But you do find a lot of systems that may have evolved over time, and might not have been originally designed with ecommerce in mind, where you get process occurring that are a little messy and less than optimal.