想問問假使我有一個網路商城
使用者甲有可能會在A商店 買了 兩個羽球拍 一顆籃球
使用者乙有可能在A商店 買了 三雙球鞋
那麼我的訂單資料庫設計欄位
是應該要每個商品都要佔據一個列會比較適合嗎
訂單編號 商品名稱 店家名稱 商品數量
A1 羽球拍 A 2
A1 籃球 A 1
A2 球鞋 A 3
我的理解是使用者甲雖然買了兩樣東西，但是這是同一筆訂單，所以訂單編號要相同
我都假設成A1這樣
可是這樣設計的話，萬一使用者甲一次買十樣商品，
那我的資料庫不就要有十列來存
想問這有更好的設計方式嗎？
另外想問另外一個問題是
如果是一般的註冊使用者帳號密碼的表單傳到後端，我知道後端
可以用name來接收
但是如果是購物車
要怎麼樣把使用者 打勾的 羽球拍 籃球
都用json傳到後端
畢竟不同商店都有不同的產品清單
這方面我也不可能去把每一個商店的購物畫面都刻一遍
問題應該很基礎
希望可以得到一些hint
事情有google過
add multiple product into shopping cart
等關鍵字，但好像效果不彰qq

1. 看你後續資料使用情境 沒有最好, 只有最適合2. A商店的羽球拍和B商店的羽球拍 是同一個羽球拍嗎

1.傳統來說確實十筆沒錯，不然就是做其他設計，一個表存key，另一個表做對應2.每個產品都要有key，傳key進後端做區別

訂單 跟 店家 可以再進一步正規化 不過這跟本版有關嗎

這是歷史資料，買了就不可該，最好不要用關聯，因為商品可以不斷改

待過一個案子是把不需要用來搜的欄位存格式化字串如 訂單:A1 data:"A,羽球拍,2,A籃球,1"不過各種方法有好壞，像這樣就是改個資料要字串全覆寫而且統計時要撈資料需要用的資料在字串內很難撈訂正：A籃球,1=>A,籃球,1

Order<->OrderDetail<->Product像前面有人提到的，正規化的部分研究一下2. 不就把商品資料建起來就好，同上一筆筆建在Product內ID, 商店名稱，商品代碼，商品中文名/英文名..看你要加啥就苦功，但是建一次就好。RDBMS看一下啊，這是最基本的

串成字串，再交由後端的字串split api處理也夠完成作業了，但是真實商城會有各種奇葩商品名稱，可能會讓split無法正常運作。不過這種問題其實應該跟同學討論場景來做表格設計還有normalization，以後出來混遇到才會瞭解學生時期設計思慮不周全，然後印象更深刻

如果一個商品很多規格呢？

多一個 shop_id 做複合主鍵就解決了至於 10 row 的問題只能跟你說，你即使存 json 之類的進去再在後端解只是徒增維護人員理解的成本DB 速度慢是要下更好的 SQL 處理

照正規化的概念就是這樣設計吧

建議原po先去看看資料庫正規化

商品很多規格要做商品類型，類型很多層一樣要再分Class Diagram畫出來不就很清楚了

訂單資料是immutable的＆一對多，你要不要用NoSQL來存？

原子性

建議還是看一下正規化比較好

這個我處理過，把訂單資訊存成json，子訂單是object arraypk設定成訂單編號，你把子訂單拆開存也是可以但是要設定子訂單編號，不要直接用訂單編號你的table不是只有存，也要複寫更改，存成json是最方便的天貓的資料同步給客戶的table 他們是這麼做的

訂單主檔一筆資料，訂單明細10筆。再去關聯商品

正規化先研究一下= =