我应该只使用一张桌子吗？
我有一个实体Order。
订单包含日期、客户、处理订单的员工等信息。
现在订单还需要存储状态，即区分赢得的订单和丢失的订单。
这个想法是，客户可以向公司提交订单，但最终可能退出。
（作为域名信息，订单不是商品。它是一家服务公司，试图与客户打交道，并就何时可以交付订单以及以什么价格等提供报价。因此，客户可能会找到更好的布尔加恩和备份以及停止公司的订购流程）。
该公司需要有关赢得订单和丢失订单的数据，赢得订单和丢失订单之间的区别只是几个属性，例如 ReasonLost 可能是 Price 或时间。
我的问题是，Order 的最佳表示是什么？
我正在考虑使用单个表，并且仅将赢得的订单的 ReasonLost 设置为 null。
如果这些新实体的差异并不显着，那么为 WonOrder 和 LostOrder 创建单独的表是否有意义？
对于这种情况，最好的模型是什么？
I have an entity Order.
The order has information on date, client, associate who handled order etc.
Now the order also needs to store a state i.e. differentiate between won orders and lost orders.
The idea is that a customer may submit an order to the company, but could eventually back out.
(As domain info, the order is not of items. It is a services company that tries to handle clients and makes offers on when they can deliver an order and at what price etc. So the customer may find a better burgain and back up and stop the ordering process from the company).
The company wants data on both won orders and lost orders and the difference between a won order and a lost order is just a couple of more attributes e.g. ReasonLost which could be Price or Time.
My question is, what would be the best representation of the Order?
I was thinking of using a single table and just have for the orders won, the ReasonLost as null.
Does it make sense to create separate tables for WonOrder and LostOrder if the difference of these new entities is not significant?
What would be the best model for this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用一张桌子。添加 OrderState 字段。
警告：如果您每天进行数百万笔交易，那么像这样的决策需要更多的关注和分析。
Use one table. Add an OrderState Field.
Caveat: If you are doing millions of transactions per day, then decisions like this need much more attention and analysis.
您可能会考虑另一种替代设计。在这种替代方案中，您保留第二个表来说明订单丢失原因，并将其与您的订单表作为可选的 1:1 关联。请注意，这实际上是超类型/子类型模式的一种实现，其中丢失顺序子类型具有一个附加属性。
它看起来像这样：
在以下任何情况下，此替代方案可能很有吸引力：
There is another alternative design that you might consider. In this alternative you keep a second table for the order lost reason and relate it to your order table as an optional 1:1. Note that this is effectively an implementation of a supertype/subtype pattern where the lost order subtype has one additional attribute.
It looks like this:
This alternative might be attractive under any of the following circumstances: