iT邦幫忙

1

產品資料庫應如何設計

最近公司要做網頁,要建立公司產品資料庫,但一種產品有多種規格,要讓網頁可以呈現商品,有許多建立方式讓小弟感覺困惑,因此想請教各位大大應該如何建立會比較好,以下提供兩種資料,

第一種(建立兩個資料表)

編號 產品名稱
1 香水
1-1 香水
2 毛巾
再根據編號去建立一個詳細資料
編號 規格
------------- -------------
1 一箱
1-1 一瓶
2 一條

第二種

編號 | 產品名稱 |規格
------------- | -------------
1 | 香水 |一箱、一瓶
2 | 毛巾 |一條

想要網頁呈現方式如下(規格部分不一定要用下拉式選單,只是想呈現一個產品有不同規格)
https://ithelp.ithome.com.tw/upload/images/20190523/20110847KIWk0DWqXt.jpg

看更多先前的討論...收起先前的討論...
第二種比較常見吧
alanx15a2 iT邦新手 5 級 ‧ 2019-05-23 11:01:48 檢舉
選第一種。這樣取出來才是兩筆資料,直接就可以做下拉式選單。
另外編號用1-1實在很奇怪,可以的話再開個子號欄位。
phes11434 iT邦新手 2 級 ‧ 2019-05-23 11:24:25 檢舉
@alanx15a2
我的點是在他們是同一項產品,如果是用第一種方式,那怎麼在php部份去抓說他們是同種商品
alanx15a2 iT邦新手 5 級 ‧ 2019-05-23 11:26:57 檢舉
所以要開子號,只要編號是1的就是香水,子號0=一箱,子號1=一瓶
抓香水只要WHERE 編號 = 1 就可以了
表一 商品
欄位 商品編號 商品名稱

表二 包裝方式
包裝編號 包裝方式

表三 產品包裝方式
產品編號 包裝編號

簡單的設計要有這三個表,你後面才能延伸網站的功能
例如 多一個產品優惠的表
欄位可以訂 優惠代碼 產品編號 優惠期間
以你問題描述表達的想法,應該是沒有設計過資料庫的經驗
甚至連資料庫設計的相關課程與書籍都沒有理解過
真實的資料庫設計,跟你描述有不短的距離
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
0
anniecat
iT邦新手 3 級 ‧ 2019-05-23 11:04:57

我在網路上有找到一個不錯的資料庫設計講解,你可以參考看看~

感覺也可以設計成,產品一個表,規格一個表,關聯一個表。

1

正常是用你第二種方式。
將規格跟品項放在一起。

但不同規格得用不同的編號處理。
也就是說,你的香水有分「箱」「瓶」的情況下
你就得將其視為不同的商品編號。

不過一般來說,如果只是單位問題的話。我一般還會再做單位不同的欄位推算
如一箱假設是12瓶。


編號1 香水 箱 可以單位轉換成 編號1-1 香水 瓶 x12
反之一樣。

phes11434 iT邦新手 2 級 ‧ 2019-05-23 11:20:36 檢舉

只是想單純讓網頁呈現出此商品有哪些規格(不考慮單位換算)
一般網頁的資料庫不就是把所想要呈現的東西都放在同一欄內(我的想法)
讓網頁可以呈現出規格有一箱跟一瓶
另外
第一種方式是不是比較用在erp的部分阿

一般來說,其實這有另外的處理方式的。
這看客戶的需求度來處理。

如果你想要讓單一商品有多重單位。
大多數有如下的做法

商品編號採用主、子表規劃
主表只有單純的商品圖片及名稱還有主編號
子表才有其訂價跟單位及子編號。

2.如果單位擴展最多兩個。那也可以直接寫在同一張表上做處理。
但一般建議在無法確定可能有兩個以上的情況下,還是會建議用子表來處理。畢竟你不同單位的訂價也不可能是一樣。一定得要分開處理。

我自已的做法是還是會將其視為兩個不同的商品。但其實我還有商品的單位轉換及對應的表做處理。
也就是說,如果我進去的是箱的。可以看到瓶的商品在旁邊。進去瓶的可以看到箱的商品在旁邊。
當然我當初這樣做是依照客戶的需求。他是認定得將其視為不同商品沒錯。但需要另外顯示標注出來有其它單位在對應的位置。
這是客戶要求的做法。所以我一開始才會這樣跟你說。

但依照你要的則是需要主商品不同單位的情況。這樣的確需要用你說的第一種來處理反而會比較好。

認真來說還是看主要的需求度來決定開發跟架構,沒有一定哪個比較好跟哪個比較不好。

1
海綿寶寶
iT邦大神 1 級 ‧ 2019-05-23 11:48:49

資料庫的設計每個人的做法都不一定相同
要看實際系統的要求

有個共同的原則是
試著用「新增、查詢、修改、刪除」四個動作去驗證設計結果是否適合
以「查詢」來說
設計的資料表越多個,查詢時就可能「先合併,後有結果」
設計的資料表越少,查詢時就可能「先剖析,後有結果」

另一個最重要的原則是
「儘可能收集所有可能的資料類型,再進行資料庫設計」

就「規格」而言
因為你現在只看到「瓶、箱」
所以你會考慮第二種設計

我舉個例子給你看

編號 產品名稱 規格
1 香水 瓶,箱,2018秋,2019春,苿莉,紫羅蘭,男用,女用,100ml,50ml
2 毛巾 條,藍色,紅色,黃色,30x50,40x70

感覺有沒有不一樣?

看更多先前的回應...收起先前的回應...
alanx15a2 iT邦新手 5 級 ‧ 2019-05-23 12:02:13 檢舉

這個例子有切中問題點,我也順便提個延伸問題:
當你今天規格真的這麼多了,你想要刪掉香水的紫羅蘭規格怎麼辦?

phes11434 iT邦新手 2 級 ‧ 2019-05-23 13:09:02 檢舉

那如果跟你的例子一樣有很多種規格,那我應如何設計較好
因為以前公司舊版的資料庫是像你的例子這樣設計
把多種規格都放在同一欄內

等你老板付我薪水
我就告訴你
/images/emoticon/emoticon33.gif

guessvic iT邦新手 4 級 ‧ 2021-06-25 16:30:48 檢舉

phes11434那你就需要做資料正規化處理了. 把規格延伸出來另做一個table.

0

完全錯誤的設計,為了之後維護的彈性,實際上應該用三個表才對

小魚 iT邦大師 1 級 ‧ 2019-05-23 14:33:21 檢舉

我也是會這樣設計

其實我不止用到三個表@@"
因為我商品圖也是有多個,還有組合包啥的。
只是初學者暫不跟他說到那麼多。
先清楚用二張表處理後,再重中思考需求度看是否要再做分表。
有時在不了解的情況下分到三個表。他可能還不清楚分三表的用法。反而造成麻煩。

不管之後要怎麼設計,從他的需求看來,基本就是三張表,
兩張表只是來亂的,這是基本常識,至少也要有一點常識,
不然也是白說的~

1
PPTaiwan
iT邦好手 1 級 ‧ 2019-05-23 14:04:42

建議你可以多使用像是 ERWIN 這類的資料庫規則制定與規劃,有文件拿出來討論,並將討論後的資訊能夠繼續傳承下去,是比較好的..

https://erwin.com/products/erwin-data-modeler/

因為你提到的資料庫規劃都很薄弱,彈性與擴大性都未知也..例如...

  1. 有沒有折扣卷的應用,就可以寫出好幾張結構圖..
  2. 庫存規劃

等其他的很多..很多...

0
混水摸魚
iT邦研究生 2 級 ‧ 2019-05-24 09:12:02

最近剛好在開發新一套EC,不管什麼規格都會有維一的料號,顏色不同就不用料號,同顏色不同尺吋也是不同料號,所以我的做法是一個料號就是一個產品,顯示方面用群組的方式建一個主產品,之後都用複製的去產生子產品,這架構可以有無限的組合子產品還可以加上子群組。

所以不管你有多少種規格組合都可以在同一個產品頁面上做選取。

有點像無限階層分類的概念。

0
清心明月
iT邦新手 3 級 ‧ 2019-05-28 21:30:26

常用簡單資料庫格式

ID 分類編碼 產品名稱(包含規格) 單位(箱、瓶、條、盒) 備注
1 001-0101-001 A牌A款香水200ml -
2 001-0101-002 A牌A款香水400ml -
3 001-0102-001 A牌B款香水100ml -
4 001-0102-002 A牌B款香水200ml -
5 001-0201-001 B牌A款香水1000ml -
6 002-0101-001 C牌A款毛巾黃色 -
7 002-0101-002 C牌A款毛巾紅色 -
ID 數量 庫存位置
1 10 門市A貨架
1 100 門市A倉庫
1 100 倉庫A
2 9 門市A貨架
3 8 門市A貨架
4 11 門市A貨架
5 12 門市A貨架
6 13 門市A貨架
7 14 門市A貨架

分類編碼:是需要設計的,用來對物品進分類,對排序搜尋很重要,這也是專門的學問。
請認真參考下面的網址內容
https://www.clearlyinventory.com/inventory-basics/how-to-design-good-item-numbers-for-products-in-inventory

產品名稱: 是產品的詳細資料,通常包括品牌、顏色、容量、尺碼等等資料,不建議分開存放到其它欄位,所以名稱的必須要嚴格設計。 有些會另外如一項「規格」欄,但我不太喜歡這樣做,原因是一般使用者會亂用,而產生後續問題。

數量:不用解說吧

單位:是度量行單位,非常重要,必須要區分清楚。

備注:不可能把所有資料都放在名上,所以這個很重要。

嚴格來說,上面的格式是不足夠用,有可能需要最低庫存量、安全庫存量,按照公司操作流程來決定。

總結來說,您問的問題,不應該只屬於資料庫問題,而是包含了公司管理、行政、程作流程、庫存賬目管理、物流運作等。

0
ronrun
iT邦新手 4 級 ‧ 2023-04-27 11:26:16

這篇雖然已是四年前的,但尚未標記答案。小弟提供一點意見。

商品表 products
所有產品使用這個當主表。
流水號主鍵 id, 主產品 master_id, 產品編碼 code, 型號 model, 數量 price, 單位 unit, 是否啟用 is_active, 是否可銷售 is_salable ...

同類型商品可以使用 master_id 這一欄做階層關聯。因此不需要拆成兩個表。一個表就可以做同表關聯。

在網站上要呈現時,商品抓 主商品,然後把其它子商品做成選項,不同顏色、尺寸等等。換句話說,任何規格不同,都可以(不必然)是一筆唯一的記錄。

選項表 options, option_values
有時候某些選項不是同類商品的選擇。例如贈品,買A送B, 而B跟A一點關係也沒有。所以不能把B記錄的master_id設成A的id。這時候就可以再使用選項表。這會是兩個表,選項主表與細項。

選項主表 options:id, name 例如
1 顏色
2 尺寸
3 贈品

選項明細表 option_values:id, option_id, name
1 1 紅色
2 1 黃色
3 1 藍色
4 2 大
5 2 中
6 2 小
7 1 贈品名稱1
8 2 贈品名稱2

商品選項表
主表 product_options
id, option_id, product_id

明細表 product_option_values
id, option_id, option_value_id, map_product_id
注意,這裡的 map_product_id, 是說這個項目對應到哪一個商品。

例如 ,將一款香水 1L 定義為主商品
products
id, master_id, name, spec
1, 0, 香水, 1L
2, 1, 香水, 500ml
3, 1, 香水, 300ml

options
1, 容量
2, 贈品

option_values
1, 1, 1L
2, 1, 500ml
3, 1, 300ml
4, 2, 贈品1名稱
5, 2, 贈品2名稱

product_options
id, option_id, product_id
1, 1, 1 (容量)
2, 2, 1 (贈品)
(以香水 1L 的主鍵 1 做關聯)

product_option_values
id, option_id, option_value_id, map_product_id
1, 1, 1, 1 商品1(上表)的 1L 對應到商品1(這裡的 map_prodeuct_id)
2, 1, 2, 2 商品1(上表)的 500ml 對應到商品2(這裡的 map_prodeuct_id)
3, 1, 3, 3 商品1(上表)的 300ml 對應到商品3(這裡的 map_prodeuct_id)
4, 2, 1, 101 商品1(上表)的 贈品1 對應到商品101(這裡的 map_prodeuct_id)
5, 2, 2, 102 商品1(上表)的 贈品1 對應到商品102(這裡的 map_prodeuct_id)
6, 2, 3, 103 商品1(上表)的 贈品1 對應到商品103(這裡的 map_prodeuct_id)

而贈品1名稱,基本上就是 商品 101 的名稱,可以另外命名。

我要發表回答

立即登入回答