iT邦幫忙

0

商品有子商品的思路?

  • 分享至 

  • xImage

想問問如果一個主商品中有多個子商品
多個子商品會有自己的庫存
請問資料庫能怎麼規劃才對呢.....?

主商品

prod_id / stock / price
1 / 0 / 0
2 / 0 / 0
3 / 0 / 0
4 / 10 / 30

子商品

sub_id(PK) / prod_id / stock / price
1 / 1 / 15 / 50
2 / 3 / 20 / 10
3 / 2 / 300 / 50
4 / 1 / 30 / 30
5 / 2 / 50 / 100

主商品4沒有子商品,所以有自己的庫存和價格
1,2,3都有自己的子商品,因此主商品沒有庫存和價格(眼神死

購物車:商品加入購物車的紀錄(我還有配送人是誰、品牌ID我就不列了)

cart_id(PK) / prod_id / quan / price

以上購物車是based on 主商品
如果將子商品加入購物車會爆炸
還有其他會爆的數據庫我就先不列了
然後還有顯示的問題
原本只會顯示主商品這很簡單
但是多了子商品,我就真的不知道怎麼做了...

我都是圍繞在主商品上
因此主商品加上子商品真的是讓我蛋疼
很好奇各位大大的經驗如何處理這些問題呢
如果是大大會怎麼做?

Luis-Chen iT邦新手 4 級 ‧ 2018-11-15 09:32:28 檢舉
我之前想過,先建立一個 商品資料表 母子商品的資料應該都一樣 所以放在同一個資料表,之後再拉出一個資料表去建立母子商品的關係
phes11434 iT邦新手 2 級 ‧ 2018-11-15 09:54:07 檢舉
用外鍵約束的方式應該可以
BOM ?
主商品 + 選擇件 ?
基本上,不管哪一種,應該都有解,你還是沒說的很詳細
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
1
海綿寶寶
iT邦大神 1 級 ‧ 2018-11-15 11:45:03
最佳解答

最基本的做法,訂兩個 table
https://ithelp.ithome.com.tw/upload/images/20181115/20001787pc0M5RClA5.png

Product,就是「商品」檔,簡單明暸
Bundle,就是「包裝組合」,一個 Bundle 裡可以有一或多種 Product,每個 Product 的數量不必然是一個(AMT)

至於這個做法對不對
就看能不能回答所有的問題
1.主商品沒有庫存和價格
這句話有點問題
沒有庫存,如何判斷可否讓使用者加入購物車
沒有價格,如何計算購物車的總金額
2.購物車是based on 主商品,如果將子商品加入購物車會爆炸
這點也是無法避免
購物車的「畫面呈現」可以以「主商品」為主
但是結帳的「總金額/庫存量」的扣除
還是得回到你的「子商品」做計算基準

進銷存系統
還有許多複雜的問題要考量(eg.商品/價格、庫存/價格都不是一對一的關係)
以上只是最基本的做法

1
wingkawa
iT邦新手 3 級 ‧ 2018-11-15 11:41:51

我的想法,由於缺乏這方面設計的實際經驗,所以僅供參考
商品就是商品,不用分成兩張表來呈現主商品、子商品
而商品間的關係用另一張表來記錄,這樣也可以實現多對多的關聯(商品可以有多個子商品,而商品也可以屬於多個母商品)

prod:
prod_id / stock / price
1       / 0     / 0
2       / 0     / 0
3       / 0     / 0
4       / 10    / 30
relation:
serial(PK)  / prod_id / sub_prod_id
1           / 1       / 2
2           / 1       / 3
3           / 2       / 
4           / 4       / 1
5           / 5       / 2
1

早前曾經規劃的做法讓你參考下,會有些不同。

我商品並未區分何謂子商品。再你所謂的子商品中,我還是將其視為一個商品。
所有的商品,都可以設定上下級;商品。如b是a的子商品。
其a的下級商品就是b,b的上級商品就會是a。

當初這樣的規劃,原本主要的目的是讓客戶在選構商品後,再出現連動性的商品可選構。(當然選構後,會有其加價構的價格,這就是後續要說明的)

先將上面大約做一下說明。然後再回來你的主要問題,我當初的設計,並非是用子商品的觀念來做設計。因為一方面並不太好控管。其對應對子商品也可能會多重商品利用的可能性。
所以我改成用「套裝商品」的做法。

也就是說,我有規劃了一組套裝商品。它也可以設定數量。但他並非是實體商品。
而是其內有包含多種商品的一種套件方式。

也就是說,我一但規劃了一個s商品為套裝商品。其設定上是屬於a跟b的一個組合。
s商品的可販賣數量為其組合商品中最小數量,但可以設定更小的值。
一但購買完成,其扣除會連帶a與b商品庫存同時扣除處理。

這是我早期的一種做法。另外套裝商品也是一起存在商品主表內,但會有另外一個套裝用子表來處理這些記錄的數。畢竟這還需要成本跟利潤的計算。

0
圓頭人
iT邦研究生 5 級 ‧ 2019-01-03 20:32:30

想到ERP學到的資料表架構
一個table記錄ITEM 一個記錄階層
商品=Y的,都可以賣
如果有下階,也就是這個商品是組合件,就要再去BOM展開其它商品

所以P1和P2,不是商品,不能單賣
P3是商品,可以單賣
ASM1是商品,可以賣,它也有下階,所以要再去BOM展開其它項目

https://ithelp.ithome.com.tw/upload/images/20190103/20106764C0wmGENByK.png
BOM
https://ithelp.ithome.com.tw/upload/images/20190103/20106764MFyIcpnkyo.png

我要發表回答

立即登入回答