想问问假使我有一个网络商城
使用者甲有可能会在A商店 买了 两个羽球拍 一颗篮球
使用者乙有可能在A商店 买了 三双球鞋
那么我的订单数据库设计字段
是应该要每个商品都要占据一个列会比较适合吗
订单编号 商品名称 店家名称 商品数量
A1 羽球拍 A 2
A1 篮球 A 1
A2 球鞋 A 3
我的理解是使用者甲虽然买了两样东西，但是这是同一笔订单，所以订单编号要相同
我都假设成A1这样
可是这样设计的话，万一使用者甲一次买十样商品，
那我的数据库不就要有十列来存
想问这有更好的设计方式吗？
另外想问另外一个问题是
如果是一般的注册使用者帐号密码的表单传到后端，我知道后端
可以用name来接收
但是如果是购物车
要怎么样把使用者 打勾的 羽球拍 篮球
都用json传到后端
毕竟不同商店都有不同的产品清单
这方面我也不可能去把每一个商店的购物画面都刻一遍
问题应该很基础
希望可以得到一些hint
事情有google过
add multiple product into shopping cart
等关键字，但好像效果不彰qq

1. 看你后续资料使用情境 没有最好, 只有最适合2. A商店的羽球拍和B商店的羽球拍 是同一个羽球拍吗

1.传统来说确实十笔没错，不然就是做其他设计，一个表存key，另一个表做对应2.每个产品都要有key，传key进后端做区别

订单 跟 店家 可以再进一步正规化 不过这跟本版有关吗

这是历史资料，买了就不可该，最好不要用关联，因为商品可以不断改

待过一个案子是把不需要用来搜的字段存格式化字串如 订单:A1 data:"A,羽球拍,2,A篮球,1"不过各种方法有好坏，像这样就是改个资料要字串全覆写而且统计时要捞资料需要用的资料在字串内很难捞订正：A篮球,1=>A,篮球,1

Order<->OrderDetail<->Product像前面有人提到的，正规化的部分研究一下2. 不就把商品资料建起来就好，同上一笔笔建在Product内ID, 商店名称，商品代码，商品中文名/英文名..看你要加啥就苦功，但是建一次就好。RDBMS看一下啊，这是最基本的

串成字串，再交由后端的字串split api处理也够完成作业了，但是真实商城会有各种奇葩商品名称，可能会让split无法正常运作。不过这种问题其实应该跟同学讨论场景来做表格设计还有normalization，以后出来混遇到才会了解学生时期设计思虑不周全，然后印象更深刻

如果一个商品很多规格呢？

多一个 shop_id 做复合主键就解决了至于 10 row 的问题只能跟你说，你即使存 json 之类的进去再在后端解只是徒增维护人员理解的成本DB 速度慢是要下更好的 SQL 处理

照正规化的概念就是这样设计吧

建议原po先去看看数据库正规化

商品很多规格要做商品类型，类型很多层一样要再分Class Diagram画出来不就很清楚了

订单资料是immutable的＆一对多，你要不要用NoSQL来存？

原子性

建议还是看一下正规化比较好

这个我处理过，把订单资讯存成json，子订单是object arraypk设定成订单编号，你把子订单拆开存也是可以但是要设定子订单编号，不要直接用订单编号你的table不是只有存，也要复写更改，存成json是最方便的天猫的资料同步给客户的table 他们是这么做的

订单主档一笔资料，订单明细10笔。再去关联商品

正规化先研究一下= =