mysql订单表如何设计？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了mysql订单表如何设计？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含8268字，纯文字阅读大概需要12分钟。

内容图文

商品表和订单表 。

通过一个表来关联。

那删除了商品，相关联的订单表如何显示出这个已经删除的商品？

订单表需要冗余商品名、商品编号、价格等基本信息。

不能只保存一个商品主键，这个是订单表的基本原则，同时生成了订单的商品是不能删除的。

订单表中引用商品表主键，删除使用状态假删。

同时引入商品的状态，总之就是反范式设计，保证一次可以获得全部要的状态，不要进行多表jion。

订单：  分为以下几种
        订单凭证（接到客户的订单表），采购订单， 销售订单，委外订单

我的数据库 该怎样设计

1：  订单类型表： 分 订购，采购，销售，委外
       订单表： 
      订单详情表：

2： 订单凭证表 - 订单凭证表详情
       采购订单

采购订单详情表
       一次类推

他们之间可以相互切换，  就是   订单凭证 （产品产线做完以后），可以转换成 销售订单

在记录订单凭证那张表里面加个状态 是否完成 如果完成了就可以打了标记 然后记录到销售订单 

不需要订单类型表，在订单表中加个订单类型的字段来记录就是了，如果防止误输入错误的订单类型，在这个字段上加约束就行了。

两个表就够了。

订单表 用一个类型字段进行区分，需要转换时直接改订单类型。
订单详情表 订单的明细记录。

相互切换 也不要 对 同一个记录进行 改标志，而是应该 完成原单，新增新单

所有单据都用一套主从表：
一个主表，有单据类型字段
一个从表

要看业务需求的。
如果一个订单按流程走下去，不同的步骤被称为不同的名称，改标志就够了。
最多加上几个时间字段，用来记录转换类型的时间点。

要是内容没变化，同样的明细复制几份没有意义，反而平白增加了数据量。

订单凭证,采购订单,销售订单,委外订单各建一个表存储(主表), 必要时建各自对应的明细表.
各种订单的主表之间可通过各自的内码(InterID)关联.

买家购买商品后，产生一个订单，那么订单进行的每个步骤的数据如付款、付款时间，发货、发货时单，确认收货等信息应该如何设计，都放在订单表中吗？

每个步骤的数据如付款、付款时间，发货、发货时单，确认收货等信息应该如何设计，都放在订单表中吗？

订单表：订单编号、下单时间、提交人、订单类型、收货人信息、订单状态[待发货-已发货等]、订单审核人、订单金额、收货人ID[来至客户信息表]、
订单商品信息记录表：订单编号、商品ID、

其实你应该是有一个顺序生成不同的单据，并不是一个订单这么简单，
客户下好单可以叫一个基本订单、确认后，生成一个付款单、再后来就是发货单、最后收到钱了还有一个
收款单、这是最基本的几个单据！

一个订单需要包含以下信息：客户信息、商家信息、产品信息、订单自定义信息（订单状态、编号等）。数据库里面与之关联的有以下表：客户表、商家表、产品表、订单表
　　
　　所遇到的问题：
　　 一个订单不只包含一个产品，如果一个订单包含2个或者两个以上的产品时，如何解决？
　　
　　当前解决方案：
　　 另外建立一张关系表、一张历史记录表。将每个订单的产品信息存入关系表里面，在查询订单明细的时候，从关系表里读出该订单的产品信息。因为关系表的增长速度非常快，为了提高查询速度，将很久以前的数据移入历史记录表里面。

你可以将定单表中唯一标识定单的字段与产品定单表中唯一标识产品的字段,重新定义一个表,在此表中,将这两个字段作为联合主键就可以了 　　你上面的解决方案,当运行到一定程度时,历史记录表会很大.查询会很麻烦 　　你可以在定单表中,增加这两个字段,并将订单状态设置成标志位,在业务逻辑中进行判断,那么此订单中,只要客有想买的商品,即可以成交. 　　谢谢您的解答,我似乎明白您的意思了.但是需要查询订单详情的时候,是不是也从新定义的这个表里获取产品的ID ,然后再从产品表里获取资料呢? 这样是不是也算是定义了一个关系表? 如果有多个产品的话,怎么解决呢?这点我还是没有搞懂,请明示. 谢谢. 你用一个新表来定义新购的产品就可以了,完全可以使用定单信息这一个表就可以了.

首先，需要表产品、订单、库存、出库这4个表，根据你的需求来说。

产品记录产品名称、产品价格等等产品信息。
订单记录订单号、订单创建人等等
库存记录产品的ID、产品总量等等
出库记录产品的ID、订单的ID、产品数量、打单员等等

这样可以通过查找出库记录的时候，根据订单的ID可以看到这个订单一共有什么产品。
其实我觉得如果你这里不涉及一个出库的需求，单纯需要知道每个订单的产品，应该有更加简洁的设计方案。

存在这样一个关系：商品，客户，订单。

每个客户对应多个订单
每个订单对应多个商品

请问如何设计订单表？

还有，所有客户的订单都存在一张表中，还是为每个客户都创建一个订单表？

商品：ID，名称，价格，。。。。
客户：ID，名称，。。。。。
订单主表：流水号，订单日期，客户ID。。。(一个订单一条)
订单辅表：流水号，主表流水号，商品ID。。。(同一主表的流水下对应多个商品 )

 典型的购物车案例，  用户在商城购买商品， 同一个商品可以购买多次。 最后形成一个订单。我的数据库是这样设计的：

     因为一个订单可以包含很多商品条目， 而一个商品也可以由很多订单订购。所以2者是多对多的关系。  另外还有需求，用户可以修改订单中商品的数量， 就是说，用户可以买10个或者更多个商品。

     表设计如下

     Order(订单表):
     ............ id, int
     ............ name,string


     Product(商品表)
     ............ id, int
     ............ name,int

    
     Ref_OP(订单商品关联表)
     ............ order_id, int
     ............ product_id, int
     ............ quantity, int   /**  一个订单同一个商品的数量 */
     
     请注意，最后的关联表 中有个 quantity ， 我想和各位探讨的是， 这样的设计是否合理？

很不合理。
订单表管理的订单，商品表管理的是库存。他们没有关系的。

需要有订单表，订单明细表和商品表，其中商品表和订单明细没有关联，记入明细时需要复制全部商品信息。

---

很不合理。
订单表管理的订单，商品表管理的是库存。他们没有关系的。

需要有订单表，订单明细表和商品表，其中商品表和订单明细没有关联，记入明细时需要复制全部商品信息。

拿京东网来举个例子：

如果没有关联，就是说，我在查看订单时，在订单里看到的商品信息都是订单详细表自已存储的吗？

那商品性能，描述等很多信息全存一份在订单里，太可怕了吧。

不知道我的理解是否正确：-）

为什么要这样设计？

拿京东网来举个例子：

如果没有关联，就是说，我在查看订单时，在订单里看到的商品信息都是订单详细表自已存储的吗？

那商品性能，描述等很多信息全存一份在订单里，太可怕了吧。

不知道我的理解是否正确：-）

为什么要这样设计？

考虑一下两份定单的情形，假定它们是在不同时间作成的，在这段时间里同种商品的价格单位或者描述都是可以变化的，而定单上则应记录下作成时的产品信息。因此，两份定单上对同种商品的记录可以是不同的，所以不能使用商品表里的信息。

---

Ref_OP(订单商品关联表)

这个名称取得不好，其实就是 LineItem（销售项/订单项）。

---

考虑一下两份定单的情形，假定它们是在不同时间作成的，在这段时间里同种商品的价格单位或者描述都是可以变化的，而定单上则应记录下作成时的产品信息。因此，两份定单上对同种商品的记录可以是不同的，所以不能使用商品表里的信息。

有道理。商品的价格、描述等信息是动态变化的。

商品表信息，可以分成可变，不变的（比如序列号）。

ProductSpec 中可以只放不变信息，并暂存动态数据（如最新价格）。

预期动态变化的信息，应该拷贝到 LineItem 中。

---

lodge >> 其中商品表和订单明细没有关联，记入明细时需要复制全部商品信息。

二者可以（最好）有关联。

不变信息或辅助信息，可以不用复制，如产品说明、厂家等。

全部复制会造成信息冗余。

---

lodge >> 其中商品表和订单明细没有关联，记入明细时需要复制全部商品信息。

二者可以（最好）有关联。

不变信息或辅助信息，可以不用复制，如产品说明、厂家等。

全部复制会造成信息冗余。

每份定单上的信息都是定单作成时被记录下来的，每份定单都是独立存在的，它们之间没有相互参照的关系，即便是同种商品的信息不一致，也不会破坏数据的一致性，因此这只是重复而并非冗余。
减少重复数据个人认为意义不大，这么作只能缩小数据库的大小，由于存在多对多的复杂关系容易影响检索效率。

---

事实上我认为还要考虑一下客户退货、修改订货时的数量，或者订单中某一用户的优惠（包括大客户的优惠、某节假日促销的优惠等信息），当然也可以不放在同一张表内，不过那就需要关联一些表了，如取舍要设计者根据实际情况自行把握！

---

这些都和 Use Case 有关。

脱离了系统需求来讨论表设计，等于白讨论。

---

事实上我认为还要考虑一下客户退货、修改订货时的数量，或者订单中某一用户的优惠（包括大客户的优惠、某节假日促销的优惠等信息），当然也可以不放在同一张表内，不过那就需要关联一些表了，如取舍要设计者根据实际情况自行把握！

这样考虑才全面啊

我有个问题，就是我现在有一张订单关联表，和一张订单主表，还有一张商品表。
订单关联表：
           ID 自动增长 主键
           orderId 订单编号
           productId 商品编号
           price  价格
           number  数量
----------------------------
主表:orderId订单编号
     用户名、电话、地址...

商品表:id,name...

怎么才能做到一张订单对应多个商品呢，我买东西的时候，一张单子可能会有很多商品的。 插入数据库的时候如何实现，我现在脑子里感觉只能一张订单对应一个商品呀

买家购买商品后，产生一个订单，那么订单进行的每个步骤的数据如付款、付款时间，发货、发货时单，确认收货等信息应该如何设计，都放在订单表中吗？

看你其他表的关联，建议建立主子表，将付款金额等消息，放入子表中，将发货等信息，使用ID和其他表关联

每个步骤的数据如付款、付款时间，发货、发货时单，确认收货等信息应该如何设计，都放在订单表中吗？

订单表：订单编号、下单时间、提交人、订单类型、收货人信息、订单状态[待发货-已发货等]、订单审核人、订单金额、收货人ID[来至客户信息表]、
订单商品信息记录表：订单编号、商品ID、
<br style="color:rgb(51,51,51); font-family:Helvetica,Tahoma,Ari 本文系统来源：http://blog.csdn.net/u010098331/article/details/51376077

内容总结

以上是互联网集市为您收集整理的mysql订单表如何设计？全部内容，希望文章能够帮你解决mysql订单表如何设计？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---