最基本的做法，訂兩個 table

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BOM