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

[ntpuisbest (阿龍)]

想問問假使我有一個網路商城

使用者甲有可能會在A商店 買了 兩個羽球拍 一顆籃球

使用者乙有可能在A商店 買了 三雙球鞋

那麼我的訂單資料庫設計欄位

是應該要每個商品都要佔據一個列會比較適合嗎

訂單編號    商品名稱    店家名稱   商品數量

A1                羽球拍           A                    2
A1                籃球               A                    1
A2               球鞋               A                    3

我的理解是使用者甲雖然買了兩樣東西，但是這是同一筆訂單，所以訂單編號要相同

我都假設成A1這樣

可是這樣設計的話，萬一使用者甲一次買十樣商品，

那我的資料庫不就要有十列來存

想問這有更好的設計方式嗎？

另外想問另外一個問題是

如果是一般的註冊使用者帳號密碼的表單傳到後端，我知道後端

可以用name來接收

但是如果是購物車

要怎麼樣把使用者 打勾的 羽球拍 籃球

都用json傳到後端

畢竟不同商店都有不同的產品清單

這方面我也不可能去把每一個商店的購物畫面都刻一遍

問題應該很基礎

希望可以得到一些hint

事情有google過

add multiple product into shopping cart

等關鍵字，但好像效果不彰qq


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.91.22.53 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1623612131.A.33C.html
→ kkkoooiii2: 1. 看你後續資料使用情境 沒有最好, 只有最適合
→ kkkoooiii2: 2. A商店的羽球拍和B商店的羽球拍 是同一個羽球拍嗎
不一樣，所以我想表格欄位應該從商品名稱改成商品編號，然後店家名稱應該可以刪掉

只是我這樣是不是要新增一個欄位是訂單的主鍵
因為訂單編號會重複，但主鍵不會

訂單的主鍵如果叫id 可能是 1,2,3,4,5,6,7

只是這個主鍵看起來沒有訂單編號有用?

→ Kitten1156: 1.傳統來說確實十筆沒錯，不然就是做其他設計，一個表
→ Kitten1156: 存key，另一個表做對應
存key 也是一種商品存一個列嗎？不然看起來好像也是買十樣存十列?

→ Kitten1156: 2.每個產品都要有key，傳key進後端做區別
→ siriusu: 訂單 跟 店家 可以再進一步正規化 不過這跟本版有關嗎
→ MonyemLi: 這是歷史資料，買了就不可該，最好不要用關聯，因為商
→ MonyemLi: 品可以不斷改
推 somefatguy: 待過一個案子是把不需要用來搜的欄位存格式化字串
→ somefatguy: 如 訂單:A1 data:"A,羽球拍,2,A籃球,1"
→ somefatguy: 不過各種方法有好壞，像這樣就是改個資料要字串全覆寫
→ somefatguy: 而且統計時要撈資料需要用的資料在字串內很難撈
→ somefatguy: 訂正：A籃球,1=>A,籃球,1
→ bheegrl: Order<->OrderDetail<->Product
→ bheegrl: 像前面有人提到的，正規化的部分研究一下
→ bheegrl: 2. 不就把商品資料建起來就好，同上一筆筆建在Product內
→ bheegrl: ID, 商店名稱，商品代碼，商品中文名/英文名..看你要加啥
→ bheegrl: 就苦功，但是建一次就好。RDBMS看一下啊，這是最基本的
→ BlacksPig: 串成字串，再交由後端的字串split api處理也夠完成作
→ BlacksPig: 業了，但是真實商城會有各種奇葩商品名稱，可能會讓s
→ BlacksPig: plit無法正常運作。不過這種問題其實應該跟同學討論場
→ BlacksPig: 景來做表格設計還有normalization，以後出來混遇到才
→ BlacksPig: 會瞭解學生時期設計思慮不周全，然後印象更深刻
※ 編輯: ntpuisbest (219.91.22.53 臺灣), 06/14/2021 08:49:41
推 gorocky: 如果一個商品很多規格呢？
推 xxxxae86: 多一個 shop_id 做複合主鍵就解決了
→ xxxxae86: 至於 10 row 的問題只能跟你說，你即使存 json 之類的進
→ xxxxae86: 去再在後端解只是徒增維護人員理解的成本
→ xxxxae86: DB 速度慢是要下更好的 SQL 處理
推 holebro: 照正規化的概念就是這樣設計吧
推 sherees: 建議原po先去看看資料庫正規化
推 KY1998: 商品很多規格要做商品類型，類型很多層一樣要再分
→ KY1998: Class Diagram畫出來不就很清楚了
推 MyNion: 訂單資料是immutable的＆一對多，你要不要用NoSQL來存？
推 new122851: 原子性
推 bill0205: 建議還是看一下正規化比較好
推 acgotaku: 這個我處理過，把訂單資訊存成json，子訂單是object arr
→ acgotaku: ay
推 acgotaku: pk設定成訂單編號，你把子訂單拆開存也是可以
→ acgotaku: 但是要設定子訂單編號，不要直接用訂單編號
→ acgotaku: 你的table不是只有存，也要複寫更改，存成json
→ acgotaku: 是最方便的
→ acgotaku: 天貓的資料同步給客戶的table  他們是這麼做的
推 waypin2002: 訂單主檔一筆資料，訂單明細10筆。再去關聯商品
推 rahit: 正規化先研究一下= =