首页 新闻 搜索 专区 学院

订单状态的表设计问题。

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都放在数据库的自定义函数中,不是办法的办法。

   想想这个订单状态也是头疼,企业内部的不同角色有不同的操作,客户也有不同的查询订单需求。请教大家,上面的思路怎么样? 怎么去变得更好?先谢谢了。

    

  

小棋的主页 小棋 | 初学一级 | 园豆:46
提问于:2018-04-05 23:45
< >
分享
最佳答案
0

这是一大堆问题,不是一个问题啊!能回答的我随便回答下,

1、单表和两个表各有优缺点,比如说,单表打印的时候方便。至于拼接SQL的事情,不作评论,你以后学着学着自然知道如何不拼接SQL了。

2、这不是问题。

3、有个简单的方法,比如说用整数代表状态的话,低于20(已收货)的订单都是未收货的,这样就只需要 where Status<20即可。

收获园豆:20
爱编程的大叔 | 高人七级 |园豆:30663 | 2018-04-06 09:14

其实,我想问的,或者这个问题引起的问题有很多。

(1) 要非常清晰地了解当前的业务场景,和估算日后的业务变化,至少能确定多表或单表,其实我觉得耶是业务建模的问题。所以,我在想这个问题的时候,是对业务建模没有底气,才会导致单表、多表的事。因为这个平台的内部业务细节多,场景应用也多,林子大了,感觉自己啥鸟都不好使。需求获取、业务分析、建模,其实就是开始编码之前的问题一大堆问题,导致码不好写。同样地,因为之前的问题,暂时使用的是拼接sql,以后重构。

(2)问题2 ,是表达一种思路,不是问题。是想问问大家,这种方法好吗?

(3)你说的这个方法,我以前用过。基本是解决现在的问题,没有考虑到扩展和变化。还有不太想用类似硬编码方式,能不用就不用。我之前想过状态机,可惜没有想下去。

其实,这些问题是个大问题,类似于如何设计好电商订单处理业务,然后是表设计、然后是编码。

小棋 | 园豆:46 (初学一级) | 2018-04-06 10:01

@小棋: 个人观点,这种需要自己读两三年书(最起码)的,并不适合这样问。

1、如果是业务场景,差别是很大的,而你又没有说明你的业务场景。

2、如果是设计,网上起码有成千上万篇的文章,关键还是那几篇适合你,而适合这种事情,只有了解才能适合。又回到问题一。

3、我们总是有幻想,有个人说了一句话,然后我们自己需要学习十年八年的东西突然醍醐灌顶了,一下明白了,然而这些只能是幻想。

4、一大堆的问题,想问的话,最好还是自己能先拆成一个个的小问题,然后自己组织,选择适合自己的解决方案。

5、其实真正的解决方案是有的,不过一般网友不会接受,那就是付费咨询,找真正的高手,考察你的企业情况,给出建议,当然,大部分的企业都觉得这是不可能的,我自己能做的事情为啥要给钱让别人帮我做。

爱编程的大叔 | 园豆:30663 (高人七级) | 2018-04-06 10:47

@爱编程的大叔:  开始到现在,我也觉得不合适这样去问。毕竟这个不是一个简单的问题。这类的问题其实还是得靠自己去想,涉及的因素多。不过,这两天倒是有点眉目。不是技术上的突破,只是从工程实践上考虑。还是自己有点嫩。作为技术员,眼光太窄。之前想得复杂了。总想着能解决技术的问题,稍微好点设计和编码,设计图画好,产品少BUG、寿命长,用户满意,股东赞同,新员工上手容易,尽量少培训,唉,真觉得自己傻。

小棋 | 园豆:46 (初学一级) | 2018-04-06 16:34
其他回答(1)
0

对于订单合同一类的表设计,个人更倾向于一张表信息完整,也就是一个流程下来数据都可以在一张表上可以找到。简单订单表应包含(通用字段),订单号,用户id,用户信息,产品id,产品信息,发货地址,联系电话,应付金额,实付金额,支付时间,发货时间,快递信息,收货时间;信息完整是防止数据被删除和查找方便,状态也可以按字段存在判断或存状态。

TCG2008 | 园豆:1145 (小虾三级) | 2018-04-06 11:17

不好意思,让大家看迷糊了。其实我不单是问表设计的问题,是一大堆的问题。(1)这个问题只是从纯技术的考虑 (2)没有描述应用场景(3)问题的所需的目标 (4)等等 。想得太仓促,文不对题,见谅。

现在的思路是:(1)尽快完成产品,比较还有进度紧(2)在合适的时候重构或者升级,等有利润和时间合适,可以请人来解决,没必要事事去亲历。(3)凡事多角度去考虑,技术员(编码好),市场推销(尽快完成),股东(短时间、少投资),新员工(编码尽量傻逼化),客户(基本能用,以后完善),竞争者(不用NB的产品,只要合适的产品去抢市场份额),系统设计(不要过度设计,简化)。(4)大前提想好了,其他的细节,我也不想去纠结了。

支持(0) 反对(0) 小棋 | 园豆:46 (初学一级) | 2018-04-06 16:49
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册