想問問假使我有一個網路商城
使用者甲有可能會在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→ kkkoooiii21樓1. 看你後續資料使用情境 沒有最好, 只有最適合 06/14 04:53
→ kkkoooiii22樓2. A商店的羽球拍和B商店的羽球拍 是同一個羽球拍嗎 06/14 04:53
不一樣，所以我想表格欄位應該從商品名稱改成商品編號，然後店家名稱應該可以刪掉
只是我這樣是不是要新增一個欄位是訂單的主鍵
因為訂單編號會重複，但主鍵不會
訂單的主鍵如果叫id 可能是 1,2,3,4,5,6,7
只是這個主鍵看起來沒有訂單編號有用?
→ Kitten11563樓1.傳統來說確實十筆沒錯，不然就是做其他設計，一個表 06/14 05:59
→ Kitten11564樓存key，另一個表做對應 06/14 05:59
存key 也是一種商品存一個列嗎？不然看起來好像也是買十樣存十列?
→ Kitten11565樓2.每個產品都要有key，傳key進後端做區別 06/14 05:59
→ siriusu6樓訂單 跟 店家 可以再進一步正規化 不過這跟本版有關嗎 06/14 06:07
→ MonyemLi7樓這是歷史資料，買了就不可該，最好不要用關聯，因為商 06/14 07:52
→ MonyemLi8樓品可以不斷改 06/14 07:52
somefatguy9樓待過一個案子是把不需要用來搜的欄位存格式化字串 06/14 08:04
→ somefatguy10樓如 訂單:A1 data:"A,羽球拍,2,A籃球,1" 06/14 08:06
→ somefatguy11樓不過各種方法有好壞，像這樣就是改個資料要字串全覆寫 06/14 08:07
→ somefatguy12樓而且統計時要撈資料需要用的資料在字串內很難撈 06/14 08:08
→ somefatguy13樓訂正：A籃球,1=>A,籃球,1 06/14 08:09
→ bheegrl14樓Order<->OrderDetail<->Product 06/14 08:14
→ bheegrl15樓像前面有人提到的，正規化的部分研究一下 06/14 08:18
→ bheegrl16樓2. 不就把商品資料建起來就好，同上一筆筆建在Product內 06/14 08:22
→ bheegrl17樓ID, 商店名稱，商品代碼，商品中文名/英文名..看你要加啥 06/14 08:23
→ bheegrl18樓就苦功，但是建一次就好。RDBMS看一下啊，這是最基本的 06/14 08:24
→ BlacksPig19樓串成字串，再交由後端的字串split api處理也夠完成作 06/14 08:36
→ BlacksPig20樓業了，但是真實商城會有各種奇葩商品名稱，可能會讓s 06/14 08:36
→ BlacksPig21樓plit無法正常運作。不過這種問題其實應該跟同學討論場 06/14 08:36
→ BlacksPig22樓景來做表格設計還有normalization，以後出來混遇到才 06/14 08:36
→ BlacksPig23樓會瞭解學生時期設計思慮不周全，然後印象更深刻 06/14 08:36
gorocky24樓如果一個商品很多規格呢？ 06/14 10:04
xxxxae8625樓多一個 shop_id 做複合主鍵就解決了 06/14 10:52
→ xxxxae8626樓至於 10 row 的問題只能跟你說，你即使存 json 之類的進 06/14 10:54
→ xxxxae8627樓去再在後端解只是徒增維護人員理解的成本 06/14 10:54
→ xxxxae8628樓DB 速度慢是要下更好的 SQL 處理 06/14 10:54
holebro29樓照正規化的概念就是這樣設計吧 06/14 16:54
sherees30樓建議原po先去看看資料庫正規化 06/14 17:10