订单商品统计是否需要单独分表？

[设计手]

商品的分类是动态的，品类比较多

比如：水果类-苹果、香蕉、橘子
劳保类-手套、扳手、钳子

一张订单内会有好几个大类，也会只有一类

比如提交过来，水果类，苹果有50个，香蕉有10个，劳保类，手套10双

后期只想统计出来，水果类有多少销售，或者劳保类有多少销售，只统计大类，小类不管


现在的想法是单独做个数据表，又考虑到订单也是动态的，会有加减，单独做表要照顾的太多了


有点乱，求大神指点迷津，十分感谢！！

[二月十六]

订单表结构什么样的？楼主说一个订单内有好几个大类？

[设计手]

大类是动态的，比如现在有水果类、劳保类、生鲜类，可能后续还会有机电类、五金类


订单结构可以修改，是否需要把商品和商品数量单独建一个表？还是放在订单表里面？

[设计手]

现在的想法是： 订单表里面单独一个字段存放：【水果类-数量；劳保类-数量；】，需要用的时候比对，一个一个的分割出来

不知道这样是否可以？

[RINK_1]

如果大类和小类的对应关系一旦确定就不会再变化，那你可以在订单的商品明细子表里也记录大类字段。否则，还是每次统计时关联到大类和小类的关系表后再统计。

[疯狂的疯]

引用 6 楼 设计手 的回复:

楼上这个适用于大型的订单系统 订单、订单明细、产品表、产品分类都是单独的存放 我感觉调用的时候太过于繁琐了吧，要去匹配的东西太多太多了 有没有简单点的。。。实在不想太麻烦了

这不是繁琐，是规范，这点儿规范都没有，以后随便加点扩展都能累死你。。。

[疯狂的疯]

可以参考下

--订单
create Table Orders(
Id int Identity(1,1) primary key,
No varchar(50) not null,
DateCreate date
)
--订单明细
Create Table OrderDetails(
Id int Identity(1,1) primary key,
OrderId int not null,
ProductId int not null,
Quantity int not null,
DateCreate date
)
--产品表
Create Table Products(
Id int Identity(1,1) primary key,
CatagoryId int not null,
NumberPackNum int not null,
DateCreate date
)
--产品分类表
Create Table Catagory(
Id int Identity(1,1) primary key,
No char(2) not null,
DisplayName varchar(30) not null,
DateCreate date
)

ALTER TABLE OrderDetails  ADD  CONSTRAINT [PK_OrderDetails_Orders] FOREIGN KEY(OrderId)
REFERENCES Orders ([id])

ALTER TABLE OrderDetails  ADD  CONSTRAINT [PK_OrderDetails_Products] FOREIGN KEY(ProductId)
REFERENCES Products ([id])

ALTER TABLE Products  ADD  CONSTRAINT [PK_Products_Catagory] FOREIGN KEY(CatagoryId)
REFERENCES Catagory ([id])

[设计手]

楼上这个适用于大型的订单系统

订单、订单明细、产品表、产品分类都是单独的存放

我感觉调用的时候太过于繁琐了吧，要去匹配的东西太多太多了

有没有简单点的。。。实在不想太麻烦了