可以先想想后面可能需要的功能，像是:
- 订单快照功能，保留当时的商品资讯 e.g. 价钱，规格等
- 是否需要跨商店结帐?
- 出货时需不需要做到分批出货?
- 退款时需不需要做到只退款部分商品?
- 出报表支援商业决策，譬如说过去一个月，哪间商店营业额最高? 哪些商品最热卖?
再来考虑可能的数据库设计
1. 一个商品一笔纪录，通通放进 orders table
- 反正规化，每次看到心情都有一点啊砸
- 做分析的时候都要考虑有多笔商品存在，通常都需要多一次 group by
2. 用 json 或是 string concat 来把商品资讯放进同一个字段，通通放进 orders
table
- 做分析有点麻烦，如果想要追踪特定商品的历史销售数据，会需要扫整张表
3. 把商品跟订单资讯拆开，商品另外有一张 order_details 来记录每笔商品，同
@bheegrl 大大推文
- 几乎每次都需要 join details table。看 UI 呈现，也可以反正规化解决
我会选 3 拉，弹性比较大，join 麻烦可以用 ORM 解决
一个订单有十笔纪录，table 成长很快的问题会倾向用 index, partitioning 来解决

推，虽然看不太懂qq

简单说就是做2张表 一个是订单表（pk:订单编号，不含商品资讯）一个是订单商品表（fk:订单编号，一个商品一笔record）好处是正规化、操作弹性 缺点是要捞整笔订单资讯时要join才捞得出来

订单表应该算历史纪录，应该完整记录商品资料用join如果店家修改商品资讯，使用者查历史订单可能会有困惑

推这篇~讲得很好

我觉得他是要交作业…大哥你是要做商用系统…

不是作业，算是自学作品哈

专业推

推