网上商店实施：订单状态？
大家好，我的程序员同事们，
我正在从头开始设计和编程一家在线商店。 它有一个模块来管理通过前端收到的“订单”。
我需要有一个状态来了解订单在某个时刻发生的情况，假设状态是：
- 待付款
- 已确认 - 等待发货
- 已发货
- 已取消
我的问题很简单，但对于决定商店非常重要设计，并且是：您会做什么来存储此状态：您会在订单表中为其创建一列，还是只是“计算”每个订单的状态，具体取决于每个订单是否已收到付款或已发货命令？ （除了我认为 is_cancelled 列）
模拟此类问题的最佳方法是什么？
PD：我什至希望将来可以配置这些状态，购买使用相同软件的其他客户。
Hello Again my fellow programmers out there,
I'm designing and programming from scratch a online shop. It has a Module to manage "Orders" that are recieved via the frontend.
I'm needing to have a status to know whats happening with an order in s certain moment, let's say the statuses are:
- Pending Payment
- Confirmed - Awaiting shipment
- Shipped
- Cancelled
My question is a simple one, but is very important to decide on the store design, and is: What would you do so store this status: Would you create a column for it in the Orders table or would you just "calculate" the status of each order depending if payments has been recieved or shipments has been made for every order? (except I suppose for a is_cancelled column)
What would be the best approach to model this kind of problem?
PD: I even wish in the future to have these statuses configurable buy other clientes using the same software..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您的订单表中将有一个 status_id 列，然后是一个单独的orders_status 表，其中包含 ID 和状态描述：“待处理、暂停”等。
订单完成后，您的支付模块会将状态设置为待处理。
我倾向于使用其他两个字段： -
布尔值 is paymentcompleted 指示订单是否实际上已按付款条件完成并准备好处理。 如果您仅在付款成功后保存订单详细信息，这不是问题。
然后，我将有一个 isneworder 布尔字段，用于突出显示管理系统中的新订单，并快速确定需要处理的新订单。
附言。 您确实需要跟踪订单的订单状态。 即时计算会导致灵活性降低。 这是我遇到的所有电子商务系统的标准实现。
You would have a status_id column in your orders table, then a separate orders_status table with the ids and status descriptions: 'pending, on hold' etc.
Your payment module upon completion of an order will set the status to pending.
I tend to have two other fields: -
Boolean ispaymentcompleted to indicate whether the order has actually been completed in payment terms and is ready to be processed. This is not an issue if you only save the order details after successful payment.
Then I'll have a isneworder boolean field simply to highlight the new orders in the admin system and also to quickly determine new orders that need to be processed.
PS. You do need to keep track of order status for an order. Calculating on the fly will lead to less flexibility. And this is standard implementation for all the ecommerce systems I have encountered.
您可以用我目前想到的两种不同的方式来完成：
选项一：
创建一个订单表并插入一个列，根据订单的数量显示 0、1、2 或 3。状态群岛
在另一个表中，主键从 0 升序到 3（如上所述），下一列显示：状态为 varchar 或字符串，具体取决于您的 sql 服务器。 您可以在其中插入“待处理”之类的内容
选项二：
您将其存储在每个订单的额外列中。 根据订单量，这是小型商店的最佳解决方案。 随着订单量越来越大，这需要越来越多的时间。
第二种解决方案较慢的原因是，通常选择字符串比选择整数值慢。
问候
You could do it in two different styles of which I can think at the moment:
Option one:
Create a Table for Orders and insert a Column that says 0,1,2 or 3 depending on the amount of statuses is.
In another table the primary Keys are ascending from 0 to 3 (as above) and the next colum says: status as a varchar or string, depending on your sql server. There you can insert stuff like 'pending'
Option two:
You store it in an extra colum on each order. Depending on the amout of orders, this is the best solution for small shops. With the amount of orders getting bigger this takes more and more time.
The reason why the second solution is slower is that in general selecting strings is slower than selecting integer values.
Greetings
我将存储订单中每一行的状态。
您需要考虑是否有人订购了 2 件商品然后取消了其中一件。
I would store the status against each line in the order.
You need to take into account if someone orders 2 things then cancels one of them.
为
Orders创建状态列 基本原理是，如果
Orders可以与多个Payments或Invoices关联（取决于在您的实施中），那么订单的状态不与任何一个待处理或已完成的有绝对关系付款，因此无法直接计算。订单可以标记为已付款或已完成即使尚未收到付款。 订单准确地表示：按计划发货给客户。 它不应代表实际收入，而实际收入又是付款表的域。确切的实施将取决于您的工作流程； 我之前已将“已完成”订单视为付款的“替代品”，但它变得混乱。 特别是当您进行促销或想要赠送库存并且必须考虑库存损失且没有收到收入时。 欢迎来到会计地狱。
当收到订单的
付款时，您的业务逻辑应该决定是否调整订单的状态。 如果订单处于待处理状态，并且现在收到的付款总额等于或大于订单价值，则订单应标记为已付款，表明已准备好发货。总结：已完成的
付款代表收入，而已完成的订单代表发货和/或库存变化。Create a status column for
OrdersThe rationale is that if
Orderscan be associated with multiplePaymentsorInvoices(depending on your implementation), then the status of anOrderdoes not have an absolute relation to any one pending or completedPaymentand hence is not directly calculable.An
Ordercould be marked as Paid or Completed even though no payment has been received for it. An order represents exactly that: a scheduled shipment to a customer. It should not be representative of actual income, which in turn is the domain of yourPaymentstable.Exact implementation will depend on your workflow; I have accounted "completed" orders as "substitutes" for payments before, but it gets messy. Especially when you run promotions or want to give stock away and have to account for lost stock and no income received. Welcome to Accounting Hell.
When a
Paymentis received for an order, your business logic should decide whether to adjust the status of the order. If the order was pending and the total received Payments now add up to equal to or more than the order value, theOrdershould be marked as Paid, indicating that it is ready to be shipped.To summarise: Completed
Paymentsrepresent income, whereas CompletedOrdersrepresent shipments and/or stock changes.如果您可以计算它，您应该计算它。 否则，您将拥有冗余数据并面临不一致的风险。
这并不是说出于性能原因或为了使查询更容易而不能添加状态列，而是从不添加状态列开始，并确保您的权威数据保持这种状态。 就我个人而言，我更喜欢坚持使用计算查询方法，除非我可以证明性能不够好。
If you can calculate it, you should calculate it. Otherwise you have redundant data and run the risk of having inconsitencies.
That's not to say you can't add a status column for performance reasons or to make querying easier, but start without it and make sure your authoritative data stays that way. Personally I prefer to stick with the calculate-on-query approach unless I can prove the performance isn't good enough.