精华内容
下载资源
问答
  • 订单表
    千次阅读
    2021-02-05 22:22:17

    Mysql数据库下订单表如何设计

    商品表和订单表 。

    通过一个表来关联。

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

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

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

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

    同时引入商品的状态,总之就是反范式设计,保证一次可以获得全部要的状态,不要进行多表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、

    其实你应该是有一个顺序生成不同的单据,并不是一个订单这么简单,

    客户下好单可以叫一个基本订单、确认后,生成一个付款单、再后来就是发货单、最后收到钱了还有一个

    收款单、这是最基本的几个单据!

    请各位牛人指教,一个困扰我很久的订单表设计问题

    旅游电商订单表设计问题问题描述:网站提供酒店,机票,旅游线路等等...多种产品的预定。用户可以同时预定多个产品,怎么把这么多不同类型的产品糅合到一个订单记录中也就是一个订单号。因为这些产品的每个订单属性都不一样。一个订单记录怎么去做这么多种订单的订单详情关联,,例如:订单号是DK3453545,那这个订单号里用户是预定了机票,门票,酒店,以及旅游车的那这个订单记录中该怎么把这些订单详情关联到这个订单记录中,而且这些用户需要预定的产品是不固定的。我也想过把每个产品类型的订单记作为一个单独产品类型订单记录,那么就会存在很多个订单表,当系统需要查询当前用户的订单时,就需要把所有的类型订单表都遍历一遍。这样效率太慢。而且感觉很不好维护,麻烦各位做过订单电商的牛人给点经验。

    最满意答案

    1、商品基础属性及库存(SKU)

    2、订单以及订单详情(Order&OrderItems),OrderItems里面的record肯定与某个SKU关联上。同时你们的这种订单,一定包含个性化定制信息,一般都可以用一个字段将个性化信息保存起来(比如订酒店,可能包含日期、住几晚、单间还是标间、其他特殊要求等)

    3、Shipment,订单只是与客户签订的一个意向合同,那么shipment就是你们如何去履约这个合同的载体。这种情况下,一类商品就可以设计成一种shipment,具体的履约方式、过程和状态,都可以放到这个模型里。

    总结:订单是面向用户的模型,代表着一个销售或者销售意向合同。shipment是面向内部实际操作环节的模型,代表系统如何去跟踪和记录订单的每个不同类型的商品是如何履约的。

    更多相关内容
  • SAP 采购订单 关系

    2021-02-07 14:33:17
    SAP 采购订单 关系 by Tiger
  • 产品订单表.zip

    2021-12-20 14:02:28
    产品订单表
  • 订单表设计

    2019-01-16 08:43:17
    订单表设计,电商订单表设计
  • mysql订单表如何设计?

    千次阅读 2021-01-28 14:31:47
    mysql订单表如何设计?商品表和订单表。通过一个表来关联。那删除了商品,相关联的订单表如何显示出这个已经删除的商品?订单表需要冗余商品名、商品编号、价格等基本信息。不能只保存一个商品主键,这个是订单表的...

    mysql订单表如何设计?

    商品表和订单表

    通过一个表来关联。

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

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

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

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

    同时引入商品的状态,总之就是反范式设计,保证一次可以获得全部要的状态,不要进行多表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、

    其实你应该是有一个顺序生成不同的单据,并不是一个订单这么简单,

    客户下好单可以叫一个基本订单、确认后,生成一个付款单、再后来就是发货单、最后收到钱了还有一个

    收款单、这是最基本的几个单据!

    请各位牛人指教,一个困扰我很久的订单表设计问题

    旅游电商订单表设计问题问题描述:网站提供酒店,机票,旅游线路等等...多种产品的预定。用户可以同时预定多个产品,怎么把这么多不同类型的产品糅合到一个订单记录中也就是一个订单号。??????????????因为这些产品的每个订单属性都不一样。一个订单记录怎么去做这么多种订单的订单详情关联,,????????????例如:订单号是DK3453545,那这个订单号里用户是预定了机票,门票,酒店,以及旅游车的那这个订单记录中该怎么把这些订单详情关联到这个订单记录中,而且这些用户需要预定的产品是不固定的。??????????????我也想过把每个产品类型的订单记作为一个单独产品类型订单记录,那么就会存在很多个订单表,当系统需要查询当前用户的订单时,就需要把所有的类型订单表都遍历一遍。这样效率太慢。而且感觉很不好维护,?麻烦各位做过订单电商的牛人给点经验。

    最满意答案

    1、商品基础属性及库存(SKU)

    2、订单以及订单详情(Order&OrderItems),OrderItems里面的record肯定与某个SKU关联上。同时你们的这种订单,一定包含个性化定制信息,一般都可以用一个字段将个性化信息保存起来(比如订酒店,可能包含日期、住几晚、单间还是标间、其他特殊要求等)

    3、Shipment,订单只是与客户签订的一个意向合同,那么shipment就是你们如何去履约这个合同的载体。这种情况下,一类商品就可以设计成一种shipment,具体的履约方式、过程和状态,都可以放到这个模型里。

    总结:订单是面向用户的模型,代表着一个销售或者销售意向合同。shipment是面向内部实际操作环节的模型,代表系统如何去跟踪和记录订单的每个不同类型的商品是如何履约的。

    展开全文
  • 商城项目数据库设计中订单表

    千次阅读 2021-12-06 01:17:22
    目录商城项目表设计中订单表订单主表订单与商品关联表订单历史记录表订单退货申请表订单退货原因信息表订单退货信息表订单支付信息表订单配置信息表订单表主要表结构订单状态流程货到付款订单状态流程 商城项目表...

    商城项目表设计中订单表

    订单主表

    CREATE TABLE `oms_order` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `member_id` bigint(20) DEFAULT NULL COMMENT 'member_id',
      `order_sn` char(32) DEFAULT NULL COMMENT '订单号',
      `coupon_id` bigint(20) DEFAULT NULL COMMENT '使用的优惠券',
      `create_time` datetime DEFAULT NULL COMMENT 'create_time',
      `member_username` varchar(200) DEFAULT NULL COMMENT '用户名',
      `total_amount` decimal(18,4) DEFAULT NULL COMMENT '订单总额',
      `pay_amount` decimal(18,4) DEFAULT NULL COMMENT '应付总额',
      `freight_amount` decimal(18,4) DEFAULT NULL COMMENT '运费金额',
      `promotion_amount` decimal(18,4) DEFAULT NULL COMMENT '促销优化金额(促销价、满减、阶梯价)',
      `integration_amount` decimal(18,4) DEFAULT NULL COMMENT '积分抵扣金额',
      `coupon_amount` decimal(18,4) DEFAULT NULL COMMENT '优惠券抵扣金额',
      `discount_amount` decimal(18,4) DEFAULT NULL COMMENT '后台调整订单使用的折扣金额',
      `pay_type` tinyint(4) DEFAULT NULL COMMENT '支付方式【1->支付宝;2->微信;3->银联; 4->货到付款;】',
      `source_type` tinyint(4) DEFAULT NULL COMMENT '订单来源[0->PC订单;1->app订单]',
      `status` tinyint(4) DEFAULT NULL COMMENT '订单状态【0->待付款;1->待发货;2->已发货;3->已完成;4->已关闭;5->无效订单】',
      `delivery_company` varchar(64) DEFAULT NULL COMMENT '物流公司(配送方式)',
      `delivery_sn` varchar(64) DEFAULT NULL COMMENT '物流单号',
      `auto_confirm_day` int(11) DEFAULT NULL COMMENT '自动确认时间(天)',
      `integration` int(11) DEFAULT NULL COMMENT '可以获得的积分',
      `growth` int(11) DEFAULT NULL COMMENT '可以获得的成长值',
      `bill_type` tinyint(4) DEFAULT NULL COMMENT '发票类型[0->不开发票;1->电子发票;2->纸质发票]',
      `bill_header` varchar(255) DEFAULT NULL COMMENT '发票抬头',
      `bill_content` varchar(255) DEFAULT NULL COMMENT '发票内容',
      `bill_receiver_phone` varchar(32) DEFAULT NULL COMMENT '收票人电话',
      `bill_receiver_email` varchar(64) DEFAULT NULL COMMENT '收票人邮箱',
      `receiver_name` varchar(100) DEFAULT NULL COMMENT '收货人姓名',
      `receiver_phone` varchar(32) DEFAULT NULL COMMENT '收货人电话',
      `receiver_post_code` varchar(32) DEFAULT NULL COMMENT '收货人邮编',
      `receiver_province` varchar(32) DEFAULT NULL COMMENT '省份/直辖市',
      `receiver_city` varchar(32) DEFAULT NULL COMMENT '城市',
      `receiver_region` varchar(32) DEFAULT NULL COMMENT '区',
      `receiver_detail_address` varchar(200) DEFAULT NULL COMMENT '详细地址',
      `note` varchar(500) DEFAULT NULL COMMENT '订单备注',
      `confirm_status` tinyint(4) DEFAULT NULL COMMENT '确认收货状态[0->未确认;1->已确认]',
      `delete_status` tinyint(4) DEFAULT NULL COMMENT '删除状态【0->未删除;1->已删除】',
      `use_integration` int(11) DEFAULT NULL COMMENT '下单时使用的积分',
      `payment_time` datetime DEFAULT NULL COMMENT '支付时间',
      `delivery_time` datetime DEFAULT NULL COMMENT '发货时间',
      `receive_time` datetime DEFAULT NULL COMMENT '确认收货时间',
      `comment_time` datetime DEFAULT NULL COMMENT '评价时间',
      `modify_time` datetime DEFAULT NULL COMMENT '修改时间',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单';
    

    订单与商品关联表

    CREATE TABLE `oms_order_item` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `order_id` bigint(20) DEFAULT NULL COMMENT 'order_id',
      `order_sn` char(32) DEFAULT NULL COMMENT 'order_sn',
      `spu_id` bigint(20) DEFAULT NULL COMMENT 'spu_id',
      `spu_name` varchar(255) DEFAULT NULL COMMENT 'spu_name',
      `spu_pic` varchar(500) DEFAULT NULL COMMENT 'spu_pic',
      `spu_brand` varchar(200) DEFAULT NULL COMMENT '品牌',
      `category_id` bigint(20) DEFAULT NULL COMMENT '商品分类id',
      `sku_id` bigint(20) DEFAULT NULL COMMENT '商品sku编号',
      `sku_name` varchar(255) DEFAULT NULL COMMENT '商品sku名字',
      `sku_pic` varchar(500) DEFAULT NULL COMMENT '商品sku图片',
      `sku_price` decimal(18,4) DEFAULT NULL COMMENT '商品sku价格',
      `sku_quantity` int(11) DEFAULT NULL COMMENT '商品购买的数量',
      `sku_attrs_vals` varchar(500) DEFAULT NULL COMMENT '商品销售属性组合(JSON)',
      `promotion_amount` decimal(18,4) DEFAULT NULL COMMENT '商品促销分解金额',
      `coupon_amount` decimal(18,4) DEFAULT NULL COMMENT '优惠券优惠分解金额',
      `integration_amount` decimal(18,4) DEFAULT NULL COMMENT '积分优惠分解金额',
      `real_amount` decimal(18,4) DEFAULT NULL COMMENT '该商品经过优惠后的分解金额',
      `gift_integration` int(11) DEFAULT NULL COMMENT '赠送积分',
      `gift_growth` int(11) DEFAULT NULL COMMENT '赠送成长值',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单项信息';
    

    订单历史记录表

    CREATE TABLE `oms_order_operate_history` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `order_id` bigint(20) DEFAULT NULL COMMENT '订单id',
      `operate_man` varchar(100) DEFAULT NULL COMMENT '操作人[用户;系统;后台管理员]',
      `create_time` datetime DEFAULT NULL COMMENT '操作时间',
      `order_status` tinyint(4) DEFAULT NULL COMMENT '订单状态【0->待付款;1->待发货;2->已发货;3->已完成;4->已关闭;5->无效订单】',
      `note` varchar(500) DEFAULT NULL COMMENT '备注',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单操作历史记录';
    

    订单退货申请表

    CREATE TABLE `oms_order_return_apply` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `order_id` bigint(20) DEFAULT NULL COMMENT 'order_id',
      `sku_id` bigint(20) DEFAULT NULL COMMENT '退货商品id',
      `order_sn` char(32) DEFAULT NULL COMMENT '订单编号',
      `create_time` datetime DEFAULT NULL COMMENT '申请时间',
      `member_username` varchar(64) DEFAULT NULL COMMENT '会员用户名',
      `return_amount` decimal(18,4) DEFAULT NULL COMMENT '退款金额',
      `return_name` varchar(100) DEFAULT NULL COMMENT '退货人姓名',
      `return_phone` varchar(20) DEFAULT NULL COMMENT '退货人电话',
      `status` tinyint(1) DEFAULT NULL COMMENT '申请状态[0->待处理;1->退货中;2->已完成;3->已拒绝]',
      `handle_time` datetime DEFAULT NULL COMMENT '处理时间',
      `sku_img` varchar(500) DEFAULT NULL COMMENT '商品图片',
      `sku_name` varchar(200) DEFAULT NULL COMMENT '商品名称',
      `sku_brand` varchar(200) DEFAULT NULL COMMENT '商品品牌',
      `sku_attrs_vals` varchar(500) DEFAULT NULL COMMENT '商品销售属性(JSON)',
      `sku_count` int(11) DEFAULT NULL COMMENT '退货数量',
      `sku_price` decimal(18,4) DEFAULT NULL COMMENT '商品单价',
      `sku_real_price` decimal(18,4) DEFAULT NULL COMMENT '商品实际支付单价',
      `reason` varchar(200) DEFAULT NULL COMMENT '原因',
      `description述` varchar(500) DEFAULT NULL COMMENT '描述',
      `desc_pics` varchar(2000) DEFAULT NULL COMMENT '凭证图片,以逗号隔开',
      `handle_note` varchar(500) DEFAULT NULL COMMENT '处理备注',
      `handle_man` varchar(200) DEFAULT NULL COMMENT '处理人员',
      `receive_man` varchar(100) DEFAULT NULL COMMENT '收货人',
      `receive_time` datetime DEFAULT NULL COMMENT '收货时间',
      `receive_note` varchar(500) DEFAULT NULL COMMENT '收货备注',
      `receive_phone` varchar(20) DEFAULT NULL COMMENT '收货电话',
      `company_address` varchar(500) DEFAULT NULL COMMENT '公司收货地址',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单退货申请';
    

    订单退货原因信息表

    CREATE TABLE `oms_order_return_reason` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `name` varchar(200) DEFAULT NULL COMMENT '退货原因名',
      `sort` int(11) DEFAULT NULL COMMENT '排序',
      `status` tinyint(1) DEFAULT NULL COMMENT '启用状态',
      `create_time` datetime DEFAULT NULL COMMENT 'create_time',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='退货原因';
    

    订单退货信息表

    CREATE TABLE `oms_refund_info` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `order_return_id` bigint(20) DEFAULT NULL COMMENT '退款的订单',
      `refund` decimal(18,4) DEFAULT NULL COMMENT '退款金额',
      `refund_sn` varchar(64) DEFAULT NULL COMMENT '退款交易流水号',
      `refund_status` tinyint(1) DEFAULT NULL COMMENT '退款状态',
      `refund_channel` tinyint(4) DEFAULT NULL COMMENT '退款渠道[1-支付宝,2-微信,3-银联,4-汇款]',
      `refund_content` varchar(5000) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='退款信息';
    

    订单支付信息表

    CREATE TABLE `oms_payment_info` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `order_sn` char(32) DEFAULT NULL COMMENT '订单号(对外业务号)',
      `order_id` bigint(20) DEFAULT NULL COMMENT '订单id',
      `alipay_trade_no` varchar(50) DEFAULT NULL COMMENT '支付宝交易流水号',
      `total_amount` decimal(18,4) DEFAULT NULL COMMENT '支付总金额',
      `subject` varchar(200) DEFAULT NULL COMMENT '交易内容',
      `payment_status` varchar(20) DEFAULT NULL COMMENT '支付状态',
      `create_time` datetime DEFAULT NULL COMMENT '创建时间',
      `confirm_time` datetime DEFAULT NULL COMMENT '确认时间',
      `callback_content` varchar(4000) DEFAULT NULL COMMENT '回调内容',
      `callback_time` datetime DEFAULT NULL COMMENT '回调时间',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='支付信息表';
    

    订单配置信息表

    CREATE TABLE `oms_order_setting` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `flash_order_overtime` int(11) DEFAULT NULL COMMENT '秒杀订单超时关闭时间(分)',
      `normal_order_overtime` int(11) DEFAULT NULL COMMENT '正常订单超时时间(分)',
      `confirm_overtime` int(11) DEFAULT NULL COMMENT '发货后自动确认收货时间(天)',
      `finish_overtime` int(11) DEFAULT NULL COMMENT '自动完成交易时间,不能申请退货(天)',
      `comment_overtime` int(11) DEFAULT NULL COMMENT '订单完成后自动好评时间(天)',
      `member_level` tinyint(2) DEFAULT NULL COMMENT '会员等级【0-不限会员等级,全部通用;其他-对应的其他会员等级】',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单配置信息';
    

    订单表主要表结构

    • 订单表(包括订单主表,配置信息表等)
    • 订单项与商品关联表
    • 订单历史记录表
    • 订单支付信息表
    • 订单退货表(包括退货申请表,退货原因信息表,退货信息表等)

    订单状态流程

    • 0-> 待付款
    • 1-> 已付款
    • 2-> 待发货
    • 3-> 已发货
    • 4-> 已签收货物
    • 5-> 已关闭
    • 6-> 无效订单

    货到付款订单状态流程

    • 2-> 待发货
    • 3-> 已发货
    • 4-> 已签收货物
    • 0-> 待付款
    • 1-> 已付款
    • 5-> 已关闭
    • 6-> 无效订单
    展开全文
  • 订单表分库分表的思路

    千次阅读 2022-04-19 00:00:45
    0到2千万uid,对应的订单数据到a库、a。2千万到4千万对应的订单到b库。 为什么这种方案用得比较少呢? 容易出现瓶颈吗。某个范围内的用户,下单量比较多,那么造成这个库的压力特别大。其他库却没什么压力。 2,...

    在这里插入图片描述

    按照用户id打散订单数据。

    以uid来切分数据,有两种思路:

    1,某个范围的uid订单到哪些库。0到2千万uid,对应的订单数据到a库、a表。2千万到4千万对应的订单到b库。

    为什么这种方案用得比较少呢?
    容易出现瓶颈吗。某个范围内的用户,下单量比较多,那么造成这个库的压力特别大。其他库却没什么压力。

    2,使用uid取模运算。第二种方案业界用得比较多。

    一方面、处理简单,程序上做取模运算就好了。

    另一方面、使用取模的方式,数据比较均匀分散到多个库去了。不容易出现单个库性能瓶颈。

    但是不好处也有:即要扩容的时候,比较麻烦。就需要迁移数据了。

    要扩容的时候,为了减少迁移的数据量,一般扩容是以倍数的形式增加。比如原来是8个库,扩容的时候,就要增加到16个库,再次扩容,就增加到32个库。这样迁移的数据量,就小很多了。这个问题不算很大问题,毕竟一次扩容,可以保证比较长的时间,而且使用倍数增加的方式,已经减少了数据迁移量。

    按照用户id作为key来切分订单数据,具体如下:

    1、 库名称定位:用户id末尾4位 Mod 32。

    Mod表示除以一个数后,取余下的数。比如除以32后,余下8,余数就是8。

    代码符号是用%表示:15%4=3。

    2、表名称定位:(用户id末尾4位 Dev 32) Mod 32。

    上面是用计算机术语来表示, 下面用通俗的话描述。

    1、库名称计算

    用户id的后4位数,取32的模(取模就是除以这个数后,余多少)。余下的数,是0-31之间。
    比如用户id:19408064,用最后4位数字8063除以32,余数是31,则定位到底31库。

    这样可以表示从0-31之间,总共32个数字。用这个32个数字代表着32个库名称:order_db_0、order_db_2…order_db_31

    2、表名称计算

    用户id的最后4位数,除以32,取整数。将整数除以32,得到余数,能够表示从0-31之间32个数字,表示表名称。

    表名称类似这样:order_tb_1、order_tb_2…order_tb_31。一个库里面,总共32个表名称。

    比如用户id:19408063,用最后4位数字8063除以32,得到是251.9,取它的整数是251。
    接着将251除以32,取余数,余数为27。

    为了保持性能,每张表的数据量要控制。单表可以维持在一千万-5千万行的数据。1024*一千万。哇,可以表示很多数据了。

    三、思考优点和缺点

    1,优点
    订单水平分库分表,为什么要按照用户id来切分呢?
    好处:查询指定用户的所有订单,避免了跨库跨表查询。
    因为,根据一个用户的id来计算节点,用户的id是规定不变的,那么计算出的值永远是固定的(x库的x表)
    那么保存订单的时候,a用户的所有订单,都是在x库x表里面。需要查询a用户所有订单时,就不用进行跨库、跨表去查询了。

    2,缺点
    缺点在于:数据分散不均匀,某些表的数据量特别大,某些表的数据量很小。因为某些用户下单量多,打个比方,1000-2000这个范围内的用户,下单特别多,

    而他们的id根据计算规则,都是分到了x库x表。造成这个表的数据量大,单表的数据量撑到极限后,咋办呢?

    总结一下:每种分库分表方案也不是十全十美,都是有利有弊的。目前来说,这种使用用户id来切分订单数据的方案,还是被大部分公司给使用。实际效果还不错。程序员省事,至于数据量暴涨,以后再说呢。毕竟公司业务发展到什么程度,不知道的,项目存活期多久,未来不确定。先扛住再说。
    比较好的方案是不是:又能均匀分散、又能避免单表数据量暴涨方便扩容。以前看过一篇文章介绍过使用节点来存储分库分表。笔者暂时没完整的思路。

    二、查询需求的考虑

    方案一的查询问题

    方案一的情况下,由于是按照订单号做分散数据到多个库、多个表。如果需要查询a用户的所有订单,咋办?需要跨库、跨表查询。

    这样效率低。不可行。

    方案二的查询问题

    如果是按照uid来切分订单数据,在实际应用中一些很频繁的查询需求像下面这样:

    1、后台、前台,往往是输入一个订单号,查询这个订单的数据。select操作

    2、然后修改这个订单的相关状态。update操作。

    由于是,按照用户编号将订单数据分散在各个库、各个表中。

    那输入订单号,怎么知道去哪个库、哪个表查询呢?不可能所有的库、所有表都查询一遍,效率太低,不可行。

    三、解决办法:建立用户id和订单号的索引关系表

    存储的数据包括两项:订单号、用户编号。

    思路1:既然是根据订单号分散订单数据,如果需要知道某个用户所有的订单。只要我能知道了a用户的所有的订单号,那么就可以根据订单号定位到表名称了。

    思路2:既然是根据用户id来分散订单数据的。那么只要知道了这个订单号是谁的(得到了用户id),就能知道去哪个库、哪个表查询数据了。

    这样输入订单号,可以去查询索引关系表,获取到用户编号。得到了用户编号,问题解决了。订单信息是根据用户编号分库分表的,可以直接定位到x库x表了。当创建订单的时候,就要把关系插入到表里面去了。保存关系记录时,为了减低用户等待时间,不需要实时,做成异步。加入到消息队列中去操作。

    订单用户索引关系表的性能优化:直接根据订单号取模进行分库分表

    一个订单,在创建的时候,就已经分配好给指定用户了。只是一个关系对应,以后也不会变化。 根据这个特点。订单用户索引关系表,其实可以放到内存中缓存起来应对查询需求(数据库那张索引关系表也要有,数据要持久化)。平时查询的时候,走内存缓存查询。如果查询不到,再走数据库查询一下关系。这样速度就很快了。

    思考

    一、b2b平台的订单分卖家和买家的时候,选择什么字段来分库分表呢?

    上面讨论的情况是,b2c平台。订单的卖家就一个,就是平台自己。
    b2b平台,上面支持开店,买家和卖家都要能够登陆看到自己的订单。

    先来看看,分表使用买家id分库分表和根据卖家id分库分表,两种办法出现的问题

    如果按买家id来分库分表。有卖家的商品,会有n个用户购买,他所有的订单,会分散到多个库多个表中去了,卖家查询自己的所有订单,跨库、跨表扫描,性能低下。

    如果按卖家id分库分表。买家会在n个店铺下单。订单就会分散在多个库、多个表中。买家查询自己所有订单,同样要去所有的库、所有的表搜索,性能低下。

    所以,无论是按照买家id切分订单表,还是按照卖家id切分订单表。两边都不讨好。

    淘宝的做法是拆分买家库和卖家库,也就是两个库:买家库、卖家库。

    买家库,按照用户的id来分库分表。卖家库,按照卖家的id来分库分表。

    实际上是通过数据冗余解决的:一个订单,在买家库里面有,在卖家库里面也存储了一份。下订单的时候,要写两份数据。先把订单写入买家库里面去,然后通过消息中间件来同步订单数据到卖家库里面去。

    买家库的订单a修改了后,要发异步消息,通知到卖家库去,更改状态。

    二:那可以按订单号来分库分表吗? (答:不可以

    这样分库分表的话,用户有10个订单,订单不见得都在一个库、一个表里面。查询a用户的所有订单,就会变得麻烦了。尤其是要进行分页展示,分散在不同的表,甚至不同的数据库服务器,也比较耗费性能。

    那么订单号里面,最好是要有分库分表信息。淘宝的是在订单号里面添加了卖家id末2位、买家id末2位。这样的好处是干嘛呢?直接定位到具体的库、具体的表去了?

    怎么根据这个呢。因为分库、分表的规则,买家库是按照卖家id末尾2位数分,卖家库是按照卖家id末尾两位分。

    所以,只要从订单号里面拿到了这些数字信息,就知道在哪个库,哪个表了。

    这种办法,与微信的红包订单号是类似的,末尾三位数包含了库信息、表信息。

    按照这样,其实就没必要使用订单号来计算了?

    如果是按照用户id的后4位数取模分散订单数据。那么订单号的生成,可以在后面加上用户id的后4位数。

    那么,虽然是按照用户id来对订单表分库分表的。其实可以直接根据订单号,知道这个订单在哪个库哪个表了。

    如果是b2b系统,涉及到卖家和买家。那么可以把卖家和买家的id后面4位都加进去。不过是不是订单号太长了?

    三、按照订单的时间来分表如何?

    一月一张表。一年一张表。用户的所有订单,会分散在不同的库、不同的表中。
    按照时间分,在切分订单数据的时候,业界用得比较少。
    出现如下两个问题:

    1、如果需要分页查询某个用户的所有订单数据,就会出现跨库、跨表查询。效率低。

    可以做折中:限制只能查一个范围内的订单,比如一次只能查询,一年以内或者一个月以内的订单。

    2、某个时间集中写入数据,出现瓶颈。如一个月一张表。这个月的订单量暴涨呢。那么写入新的订单数据都会操作这张表。造成性能低下。影响整个业务系统交易。

    真正好的分表方案,尽量将写数据分散到多个表去,达到分流效果,系统的并发能力就提高了。

    参考:分库分表设计

    展开全文
  • 数据库订单表设计

    千次阅读 2020-12-18 14:40:07
    订单表 (order) |-- 自动编号(order_id, 自增长主键) |-- 订单单号(order_no, 唯一值,供客户查询) |-- 商店编号(shop_id, 商店表自动编号) |-- 订单状态 (order_status,未付款,已付款,已发货,已签收,退货申请...
  • 数据源:订单表与订单明细表

    千次阅读 2021-05-18 17:53:01
    本地创建的表分为订单表与订单明细表,是语句演示数据来源,可根据需要自行创建数据库进行练习
  • 订单详情表,与,订单表 怎么做?

    千次阅读 2021-01-19 07:18:06
    detail订单详情表字段名 数据类型 默认值 允许非空 自动递增 备注id int(11) NO 是 idorderid int(11) NO 订单id号goodsid int(11) NO 商品id号name varchar(32) NO ...
  • Excel模板产品订单表.zip
  • 我最近创建了一个订单表和商品表直接的关系 中间用一张关系表来联系 ``` select o.order_id,o.order_num,o.order_time, case when order_status=-1 then '交易关闭' when order_status=0 then '已支付' when ...
  • 现在有两方面的问题,一个在订单方面,是将不同的商品放在不同的订单表中,还是放在同一的一个订单表中。平台中有多个商家,对不同商家的相同的产品还需要做区分另一个是尽量实现商家端与用户端的分离,订单与付款...
  • 产品订单表

    2021-09-02 16:30:19
    产品订单表
  • MySQL创建订单表

    千次阅读 2020-11-16 08:27:54
    创建订单表,地址表,订单项目表的sql语句如下: CREATE TABLE `project_crowd`.`t_order` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '主键', `order_num` CHAR(100) COMMENT '订单号', `pay_order_num` CHAR(100...
  • 订单系统订单表设计方案

    千次阅读 2020-03-30 14:31:54
    一年前,在上一家公司接手了一个含有订单系统的项目,业务并不复杂,但是当时令我比较困惑的是订单表的设计。 困惑的点主要是随着订单量增加,单表的存储能力将达到瓶颈,必然要采用分表的方案,那么按照什么维度...
  • SQL 模拟生成商品订单表

    千次阅读 2020-08-08 12:30:03
    比方说你需要练习操作用户交易,包含 userid(用户ID)、orderid(订单ID)、amount(订单金额)、paytime(支付时间)这几个字段,如下所示: /********************************** 现在数据库中有一张用户交易...
  • Mysql订单表如何设计?

    万次阅读 2018-03-28 00:45:56
    mysql订单表如何设计?商品表和订单表 。通过一个表来关联。那删除了商品,相关联的订单表如何显示出这个已经删除的商品?订单表需要冗余商品名、商品编号、价格等基本信息。不能只保存一个商品主键,这个是订单表的...
  • Java Web 网络商城案例演示十四(设计订单表) 订单模块 1、模型的抽取 2、提交订单 3、查询我的订单 4、订单详情 5、支付功能 6、权限过滤器 一、模型的抽取 订单:本次交易记录,描述 1、分析超市小票: 设计一个...
  • 订单表订单表 订单详情表

    千次阅读 2018-09-28 15:10:16
    订单对应多个自订单 一对多 
  • (八)订单表设计

    千次阅读 2020-02-26 18:17:13
    订单表 CREATE TABLE `t_order` ( `id` int UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT '主键', `code` varchar(200) NOT NULL COMMENT '流水号', `type` tinyint UNSIGNED NOT NULL COMMENT '订单类型:1...
  • 电商平台-订单表的设计

    千次阅读 2020-07-09 18:04:26
    买家可以在张三家买茄子,李四家买萝卜,王五家买白菜,赵六家买猪肉等那么买家就应该有个订单主表,我们称为订单表,同时还有 上面所说的具体的订单明细表,清楚的查看自己买了什么菜,多少元一斤,买了多少斤等。...
  • 订单 和 商品 ,从订单的角度来说,一个订单可以有很多商品, 一个商品也可以对应多个订单,...订单表中的order_id应该是唯一的,但是订单商品表中的order_id和item_id应该是一一对应的   通过这样来在页面显示...
  • 1、老生常谈 还是mysql的统计问题 ...order 表 订单表 正常的有金额 用户openid -------等等 一些 order_detail 有商品的goodsis 每个商品对应的数量 每次机器开机 要知道上一次关机的时候未做订单 的goodsid 数量...
  • 存放goods 扩展属性,也叫规格参数,不同类型的商品其规格参数是不一样的,服装有尺码,颜色,材料等,手机有分辨率,内存,存储,摄像头,书籍有作者,出版社 #创建商品属性对应 create table cz_goods_attr...
  • 部门(SM_DEPT) 字段名称 数据类型 是否主键 注释 DEPT_ID NUMBER Y 部门ID PARENT_DEPARTMENT_ID NUMBER N 上级部门 DEPARTMENT_NAME VARCHAR2(50) N 部门名称 用户...
  • 订单表要有的内容 地址 支付方式 商品 总金额 运费 》用户中心,全部订单 订单编号 支付状态 订单的创建时间 订单表当前状态 需要分表了 一个订单需要对应多个商品 来一个订单商品表 订单商品表...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 210,642
精华内容 84,256
关键字:

订单表