2010-08-31 85 views
0

我正在考慮如何在電子商務解決方案中構建我的MySQL數據庫。更具體地說,我正在研究產品結構。產品的電子商務結構(MySQL)

這些是我到目前爲止所提供的表格。你怎麼看?

結構

的應用的說明是多種語言。因此產品表分成2個表格。

如果產品有例如2個變體(小,中)將插入總共3行。這是因爲每個變體可以爲每個變體都有不同的信息。當產品顯示在網頁上時,產品1將顯示帶有小號&中號的下拉框。沒有變體的產品自然只會插入1行。

 
products 
id master product_number 
1 0  123 
2 1  456 
3 1  678

products_descriptions id product_id country_code image name description vat price 1 1 en-us image.jpg t-shirt Nice t-shirt 25 19.99 2 2 en-us image.jpg t-shirt Nice t-shirt 25 19.99 3 3 en-us image.jpg t-shirt Nice t-shirt 25 19.99

products_to_options product_id option_id 2 1 3 2

options id name 1 Small 2 Medium

回答

1

您的產品表是精神分裂症,其實體有時是產品,有時是變體。這導致非常繁瑣的行爲。例如,你想問「我們有多少種不同的產品?」由select count(*) from products回答,但這裏給出了錯誤的答案,要得到正確答案,您必須知道Magic Number 0和查詢select count (*) from products where master=0。 「列出所有產品以及我們對每個產品有多少變體」是另一個應該直截了當,但現在不是的查詢。還有其他的異常情況,比如說products_descriptions中的第一行是一件有價格和圖片但沒有尺寸的襯衫(尺寸存儲在變體中,但它們有自己的價格和圖片)。

您的問題聽起來像您有兩種情況下的產品:(1)可以在商店中顯示爲商品的東西;(2)可由客戶訂購的商品。 (1)可能有一個像「萬聖節T恤」這樣的名字,它可能有一個客戶看到的圖像。 (2)是客戶訂購的,所以它有(1),但也有一個變體規格,如「小」或顏色「紅」。它可能也有一個價格,並有一個order_id,所以你的店可以知道要發貨的具體物品。

你應該給每個上下文一個實體。下面是我會做

displayable_product 
id name 
1 "Baseball Cap" 
2 "T-Shirt" 

orderable_product 
id d_product_id order_id size color price 
1 1   123    red  9.99 
2 2   456  small   19.99 
3 2   789  medium   21.99 

displayable_content 
id d_product_id locale name     image 
1 1    en_US "Baseball Cap"  baseballcap.jpg 
2 1    es_US "Gorra de Beisbol" baseballcap.jpg 
3 2    en_US "Nice T-Shirt"  nicetshirt.jpg 
4 2    es_US "Camiseta"   nicetshirt.jpg 

你應該使用locale,而不是country在顯示錶佔個國家擁有超過一種語言(美國,瑞士和其他),你可能會分開sizecolor分成它自己的variants表。如果您需要關於可訂購產品的國家相關數據(如向不同國家/地區發貨的不同價格/貨幣),則您也必須提取依賴於國家/地區的可訂購表格。

+0

有趣的例子。但是如果選項的數量未知,你會怎麼做?像「Slewvless」一樣?你應該正常化嗎? – Cudos 2010-09-03 17:29:22

+0

我會盡量保持數據庫正常化。在你的情況下,我會嘗試將選項分成兩個桶:(1)那些結構上的問題,他們可能最終會出現像「今年,如果紅色,白色和藍色是多少客戶喜歡紅色提供「,以及(2)類似於描述文本而不是類別的那些。理想情況下,bucket(2)將是空的,但在現實生活中,我可以大於(1)。但基本上,如果經常在查詢中出現,我希望它正常化。如果僅用於描述中,則將其放入EAV表中即可。 – wallenborn 2010-09-03 23:16:53

相關問題