Re: [請益] 商城的訂單資料庫設計

[alex0914 (青鳥)]

可以先想想後面可能需要的功能，像是:
- 訂單快照功能，保留當時的商品資訊 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 來解決

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.50.62.58 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1623634825.A.631.html
推 ntpuisbest: 推，雖然看不太懂qq
推 SHANGOYANYI: 簡單說就是做2張表 一個是訂單表（pk:訂單編號，不
→ SHANGOYANYI: 含商品資訊）一個是訂單商品表（fk:訂單編號，一個
→ SHANGOYANYI: 商品一筆record）好處是正規化、操作彈性 缺點是要
→ SHANGOYANYI: 撈整筆訂單資訊時要join才撈得出來
→ lazarus1121: 訂單表應該算歷史紀錄，應該完整記錄商品資料
→ lazarus1121: 用join如果店家修改商品資訊，使用者查歷史訂單可能
→ lazarus1121: 會有困惑
推 viper9709: 推這篇~講得很好
推 rahit: 我覺得他是要交作業…
→ rahit: 大哥你是要做商用系統…
推 ntpuisbest: 不是作業，算是自學作品哈
推 TROA: 專業推
推 xrururururu: 推