作者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/cn.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