数据库里面的订单表和订单明细表不可以用同一个表

当然有区别了

，例如

：

你买了三件商品提交，如果只用一张表的话那买家的收货详细信息就会随着你的产品数量重复次数。这样不符合数据表设计规范，同样也使你在 *** 作方面不便。所以你需要将订单分离为两张表，其中一张放置订单信息；另一张放置订单对应的商品信息。一般包括

商品的编号、商品的数量、商品的价格、商品的所属订单号。

商品的价格列你可以视乎程序需要来定，当然你可以通过商品表的连接查询得出，但有时为了更好的实现程序的功能；你可以规划成订单详细的一列。

因为有时用户需要查看账号订单的详细，那你只要连接订单表及订单详细就可以了。

以上是我的个人观点，你觉得好就顶一下吧。

单号，相关单号，制单日期，入账日期，审核日期，制单人，审核人，入账人，客户编码，总含税金额，总数量，总订货金额，备注，打印次数，时间戳字段，主键（单号），各种默认值，再加几个备用字段方便以后扩展；表体嘛，参照表头

首先来说对于这种场景有两种设计方法，这两种方法都能够满足扩展性要求

1 把原有的横表转化为纵表存储属性，即

产品表：（product_id, product_name, product_class)

产品属性表：(product_id, property_id , property_name , property_value)

2 保持原有横表设计思路，但是d性字段含义单独元数据表存储

产品表：（product_id, product_name, product_class, prop1, prop2, propn)

产品属性含义元数据表

(product_class , prop1_name ,prop2_name, propn_name)

对于两种设计方法，个人理解为

a 对于首页打开就必须要能够快速查询出来的属性，而且这些属性本身各类产品差异不大。而对于差异大的属性基本都是针对特定一个产品查询。可以采用方案1来做。

b 首页显示产品列表时候就存在要显示出不同产品属性情况，采用方案2来做。当我们处理的是一个product list的时候，由于存在数据表本身的关联场景，用方案1会比麻烦，也影响性能。

以上就是关于数据库里面的订单表和订单明细表不可以用同一个表全部的内容，包括:数据库里面的订单表和订单明细表不可以用同一个表、数据库技术里的订单怎么设计速求、电子商务的交易记录，数据库怎么设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！