业务场景描述:
该数据库用来管理订单,但我是个小白,不知道该如何设计这个数据库结构,我自己设计的,我觉得可能不太合理
简单的说,是用来存储订单数据,并 方便后期查询,方便合并的
用户可以在线下单,然后选择自己的收货地址,然后下订单,这样的情况一张表就可以存这个订单了
但是如果用户使用购物车,同时拍下多个不同的产品,那么就必须要分表存了,一个表无法存
并且,有时候 用户会使用不同的地址,拍不同的产品
所以,我初步设计的数据库如下:
http://img.bbs.csdn.net/upload/201510/24/1445652771_429894.jpg
一个主表,一个详细表,通过这种关系,可以比较清楚的描述这个需求
但是,在实际应用中,可能需要对这个订单做二次编辑(修改地址,修改价格,修改电话 ,修改产品码数 等等),所以,上面的表,我打算用来做原子表(后期不能直接修改这 2 个表,保证它的原子性)
如果要实现可以二次编辑,就需要再增加 2 个表,来存编辑后的内容,
所以我 建立了 2 个 可编辑的表,结果和上图一样
http://img.bbs.csdn.net/upload/201510/24/1445653555_641143.jpg
,
由于,在实际情况中,会涉及到 订单的 [合并,拆分,修改产品] , 等 [复杂] 操作
所以,需要增加一个表,来描述 订单的合并 拆分关系
新的 E R 图如下:
http://img.bbs.csdn.net/upload/201510/24/1445653886_863419.jpg
通过新增的 [ edit_T2O ] 表,基本可以描述互相之间的关系,也可以解决 订单 合并,拆分,修改产品的需求
http://img.bbs.csdn.net/upload/201510/24/1445655140_574094.jpg
订单合并的逻辑:
比如 有一个用户,使用同样的地址,分别拍下 10 个订单,
那么,系统 会在 edit_T2O 表中 插入 10 个记录
订单合并的时候,首先判断 trades(主表) 里面的 用户名是否一样、收货地址是否完全一样,如果一样,便在 edit_T2O 中 插入 10 条记录里
http://img.bbs.csdn.net/upload/201510/24/1445655140_574094.jpg
用户名为 11111 的买家,拍下了 3 个订单,编号分别为 1 、 2 、 4 ,且地址一样
orders(订单详细表) 简单记录了产品信息
edit_T2O ,描述了 谁购买了什么
通过查看 edit_T20 可以发现,
用户名 11111
第一个订单购买了 qqq
第二个订单购买了 ZZZ
第三个订单购买了 ZZZ 和 q1
而用户 2222 购买了 AAA
,
这样 可以比较清晰的描述 对应的关系,
在这样的情况下,就需要对用户 11111 的几个订单进行合并
首先 用 sql 查询出 用户相同的订单信息,发现 11111 拍了多个订单,并且地址一样
系统 默认使用第一个地址作为 edit_T20 表里的 [ trades>编号] ,而 [ orders>编号] 则使用该使用的
合并之后的情况 如下:
http://img.bbs.csdn.net/upload/201510/24/1445655925_226276.jpg
然后,仓库在发货的时候,系统 就知道 要发产品,发到什么地址了,这样就实现了订单合并的功能了
而修改订单,也就方便了,直接修改对应的表即可,订单拆分,也比较简单了
请问下大家, 我上面的设计 和逻辑 是否合理, 还请多指点, 总感觉,有点奇怪 ,有点别扭