订单状态的表设计问题。
0
悬赏园豆：20
[已解决问题]
解决于 2018-04-07 09:54
这个订单是类似电商的订单。目前设计的表有订单表（order）、订单操作表（order_operate）、订单评论(order_comments)、订单明细（order_detail）。订单状态变化：开单、财务审核、付款、拣货、打包、发货、收货、评论。
订单字段记录基本信息：ID（自增）、单号、创建时间、开单人、客户、订单状态。
订单操作表：ID（自增）、订单号、操作动作、操作人、操作日期。
订单评论表：ID（自增）、订单号、评论人、评论时间、内容。
问题说明：
（1）开始时，订单这个表是包含订单表和订单操作表。但后来想，订单表应该只是包括订单的基本信息即可，至于订单的操作动作，应该是另一个表来保存这些业务动作，以便扩展。所以把一张表拆分了两个表。这个办法比一个表好吗？ 如果是同一个表的情况下，在订单状态更新时，要针对不同角色的操作，所以在更新的sql中，首先要判断是那个角色，然后是判断是什么操作。有四个角色就需要有四个if来判断（我是使用拼接sql的方式），因为更新的字段不一样（开单人、打包人、发货人等都有对应的字段）。如果是两个表的方式，只需要在订单操作记录表插入和更新某个角色的动作记录，不会出现单表的角色与字段的对应问题，直接把业务界面的角色和动作保存即可。另外如果在单表的情况下，使用ORM，也需要告诉它更新是那个字段吧 ？（这个我不熟）。所以ORM和直接拼sql可能是一样的问题。（这个问题不敢确定）
（2）订单评论表的拆分，是基于它对的订单的状态影响不是核心业务流程，所以拆分。类似的动作我也会拆分。
（3）在订单状态中，有些中间状态的，例如在拣货中，如果发现没有货了，需要挂起此单，然后去调货，货够了，再继续下一步。类似这些状态的变化， 我也放在订单表中的状态字段。但中间状态的增多的话，会有查询上的麻烦。比如，开单人要查询自己未收货的订单，这是不管什么中间状态的。那么在订单的状态值中，不管是拣货、拣货挂起、打包、打包挂起、装货、发货、发货遇到大雨、司机去打麻将等等，所以sql语句中 in （........)会有很多值，都是未完成的订单状态，这样做不利于扩展。现在，我把 in (.....)这一类的sql都放在数据库的自定义函数中，不是办法的办法。
想想这个订单状态也是头疼，企业内部的不同角色有不同的操作，客户也有不同的查询订单需求。请教大家，上面的思路怎么样？ 怎么去变得更好？先谢谢了。
最佳答案
0
这是一大堆问题，不是一个问题啊！能回答的我随便回答下，
1、单表和两个表各有优缺点，比如说，单表打印的时候方便。至于拼接SQL的事情，不作评论，你以后学着学着自然知道如何不拼接SQL了。
2、这不是问题。
3、有个简单的方法，比如说用整数代表状态的话，低于20（已收货）的订单都是未收货的，这样就只需要 where Status<20即可。
收获园豆：20
其实，我想问的，或者这个问题引起的问题有很多。
(1) 要非常清晰地了解当前的业务场景，和估算日后的业务变化，至少能确定多表或单表，其实我觉得耶是业务建模的问题。所以，我在想这个问题的时候，是对业务建模没有底气，才会导致单表、多表的事。因为这个平台的内部业务细节多，场景应用也多，林子大了，感觉自己啥鸟都不好使。需求获取、业务分析、建模，其实就是开始编码之前的问题一大堆问题，导致码不好写。同样地，因为之前的问题，暂时使用的是拼接sql，以后重构。
（2）问题2 ，是表达一种思路，不是问题。是想问问大家，这种方法好吗？
（3）你说的这个方法，我以前用过。基本是解决现在的问题，没有考虑到扩展和变化。还有不太想用类似硬编码方式，能不用就不用。我之前想过状态机，可惜没有想下去。
其实，这些问题是个大问题，类似于如何设计好电商订单处理业务，然后是表设计、然后是编码。
@小棋: 个人观点，这种需要自己读两三年书（最起码）的，并不适合这样问。
1、如果是业务场景，差别是很大的，而你又没有说明你的业务场景。
2、如果是设计，网上起码有成千上万篇的文章，关键还是那几篇适合你，而适合这种事情，只有了解才能适合。又回到问题一。
3、我们总是有幻想，有个人说了一句话，然后我们自己需要学习十年八年的东西突然醍醐灌顶了，一下明白了，然而这些只能是幻想。
4、一大堆的问题，想问的话，最好还是自己能先拆成一个个的小问题，然后自己组织，选择适合自己的解决方案。
5、其实真正的解决方案是有的，不过一般网友不会接受，那就是付费咨询，找真正的高手，考察你的企业情况，给出建议，当然，大部分的企业都觉得这是不可能的，我自己能做的事情为啥要给钱让别人帮我做。
@爱编程的大叔: 开始到现在，我也觉得不合适这样去问。毕竟这个不是一个简单的问题。这类的问题其实还是得靠自己去想，涉及的因素多。不过，这两天倒是有点眉目。不是技术上的突破，只是从工程实践上考虑。还是自己有点嫩。作为技术员，眼光太窄。之前想得复杂了。总想着能解决技术的问题，稍微好点设计和编码，设计图画好，产品少BUG、寿命长，用户满意，股东赞同，新员工上手容易，尽量少培训，唉，真觉得自己傻。
其他回答(1)
0
对于订单合同一类的表设计，个人更倾向于一张表信息完整，也就是一个流程下来数据都可以在一张表上可以找到。简单订单表应包含(通用字段)，订单号，用户id，用户信息，产品id，产品信息，发货地址，联系电话，应付金额，实付金额，支付时间，发货时间，快递信息，收货时间；信息完整是防止数据被删除和查找方便，状态也可以按字段存在判断或存状态。
不好意思，让大家看迷糊了。其实我不单是问表设计的问题，是一大堆的问题。（1）这个问题只是从纯技术的考虑 （2）没有描述应用场景（3）问题的所需的目标 （4）等等 。想得太仓促，文不对题，见谅。
现在的思路是：（1）尽快完成产品，比较还有进度紧（2）在合适的时候重构或者升级，等有利润和时间合适，可以请人来解决，没必要事事去亲历。（3）凡事多角度去考虑，技术员（编码好），市场推销（尽快完成），股东（短时间、少投资），新员工（编码尽量傻逼化），客户（基本能用，以后完善），竞争者（不用NB的产品，只要合适的产品去抢市场份额），系统设计（不要过度设计，简化）。（4）大前提想好了，其他的细节，我也不想去纠结了。
