作者alex0914 (青鳥)
看板Soft_Job
標題Re: [請益] 商城的訂單資料庫設計
時間Mon Jun 14 09:39:51 2021
可以先想想後面可能需要的功能，像是:
- 訂單快照功能，保留當時的商品資訊 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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1623634825.A.631.html
1F：推 ntpuisbest: 推，雖然看不太懂qq 06/14 14:19
2F：推 SHANGOYANYI: 簡單說就是做2張表 一個是訂單表（pk:訂單編號，不 06/14 18:28
3F：→ SHANGOYANYI: 含商品資訊）一個是訂單商品表（fk:訂單編號，一個 06/14 18:28
4F：→ SHANGOYANYI: 商品一筆record）好處是正規化、操作彈性 缺點是要 06/14 18:28
5F：→ SHANGOYANYI: 撈整筆訂單資訊時要join才撈得出來 06/14 18:28
6F：→ lazarus1121: 訂單表應該算歷史紀錄，應該完整記錄商品資料 06/14 19:04
7F：→ lazarus1121: 用join如果店家修改商品資訊，使用者查歷史訂單可能 06/14 19:05
8F：→ lazarus1121: 會有困惑 06/14 19:05
9F：推 viper9709: 推這篇~講得很好 06/14 23:36
10F：推 rahit: 我覺得他是要交作業… 06/15 12:12
11F：→ rahit: 大哥你是要做商用系統… 06/15 12:12
12F：推 ntpuisbest: 不是作業，算是自學作品哈 06/15 19:48
13F：推 TROA: 專業推 06/16 01:41
14F：推 xrururururu: 推 06/17 00:53