可以先想想後面可能需要的功能，像是:
- 訂單快照功能，保留當時的商品資訊 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如果店家修改商品資訊，使用者查歷史訂單可能會有困惑

推這篇~講得很好

我覺得他是要交作業…大哥你是要做商用系統…

不是作業，算是自學作品哈

專業推

推