标签：商品 数据库 order 订单 发票 设计 购物车 id 商城

订单系统在整个商城体系中的作用非常重要，因为一些业务的开展往往是围绕订单来展开的。因此设计好一个订单系统是多么的重要。

我们根据用户的行为逐个设计表结构。

首先用户浏览商品，将看中的商品加入到购物车，这里应该有一张购物车表

购物车表（order_cart）
----
skuId 
spuId
用户id
店铺id
商品名称
商品数量
商品价格
状态（下单之后对应商品就不应该显示在购物车了）

选中购物车中的某些商品，进行下单，订单表也就应运而生

订单表(order_info)
----
订单编号（如果对编号格式没什么要求，可使用雪花算法https://blog.csdn.net/u011499747/article/details/78254990来生成）
itemCount （商品项数量，不是商品个数，比如手机*2，鼠标*1，这里应该是2）
用户id
店铺id
下单时间
支付方式（可用数字表示，如1：支付宝，2：微信，3：银行卡...）
支付时间
outTradeNo 支付宝订单号
配送方式
期望配送日期
商品总额
运费
实际付款
订单状态（这里的状态可根据实际项目来定，可以定10,20,30..这样如果中间缺少一个状态可以添加进去）

如果购物车里面有多个店铺的商品，那么应该分别为这些店铺生成对应的订单。平台可以进行合并支付，但是订单还是要归店铺的。

上面是订单的基本信息，接下来是订单商品相关。

订单商品表(order_product)
---
订单编号
spuId
skuId
店铺id
商品名称
商品数量
商品价格

这里order_info与order_product是1对多的关系，一个订单可能有多个商品。

下单完成，等着发货，物流信息不能少，加下来是物流表

物流表（order_logistics）
---
订单标号
物流公司id
物流公司编号
快递单号
发货时间
收货时间

物流跟踪表（order_logistics_flow）
---
订单标号
物流公司标号
快递单号
remark（根据第三方接口返回来的结果信息）

加下来设计一下发票表

订单发票（order_invoice）
---
发票类型
发票抬头
发票内容
发票代码
发票号码
开票日期
校验码
密码区
服务名称
规格型号
数量
单价
金额
合计
税率
税额
销售方名称
销售方纳税人识别号
销售方地址电话
销售方开户行及账号
备注
收入款人
开票人

下单完成后进行支付，这里会有支付记录表，方便以后对账

支付记录表（order_pay_history）
---
订单编号
支付方式
订单总额
支付金额
pay_json（第三方支付平台参数信息，可使用json方式保存）
remark （备注）

用户收到货后，可以进行评论，下面是评论表

订单评论（order_product_comment）
---
spuId
skuId
评论用户id
用户昵称
点赞数
comment（评论内容）
评论分数（1~5分）
评论时间
product_info_json（评论的商品信息，如规格型号之类的）
image_json（评论图片）

好了，订单系统设计到此为了，当然围绕订单系统还有更多的业务可以开展，这里只做了一些基本的结构设计。

顺便说一句，如果一开始就想做分布式系统，建议把商品相关的表和订单表放在同一个数据库中，一则是因为订单业务需要查询商品相关的数据，二则是因为放在一起做事务比较容易，不然需要做分布式事务，加大了开发成本。前期项目规划的时候这点需要考虑到。

标签：商品,数据库,order,订单,发票,设计,购物车,id,商城
来源： https://www.cnblogs.com/yelanggu/p/12976129.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。