資料庫商品表設計

『壹』 商品分類的資料庫是怎麼設計的以滿足查詢的高效

這個三個表就應該夠了吧，一個是商品大類表，一個是品牌表，另外是商品詳細信息表
商品類別表：
ClassID
ClassName
ParentID //這個商品類歸屬的上個大類，也就是滿足你的多級分類要求

舉個例子 假設說你的鞋子分類id是1，那下屬的小類舉例說女涼鞋，她的ParentID就是1，明白？

品牌表：
BrandID
BrandName
BrandDescription

商品詳細信息表：
GoodId
ClassID
BrandID
GoodName
GoodDescription
GoodURl
還有其他你想加的屬性

『貳』 產品對應多個分類，資料庫如何設計最合理

這個要看產品的屬性的相似度吧，如果相似度很高用一張表就好了。如果相似度低，就抽取公共屬性建一張產品表，根據情況再建幾長擴展屬性表吧。

『叄』 產品資料庫表設計

按照你的描述，產品和產品的裝箱率的關系是多對多的關系，一個產品可能有多個裝箱率，一個裝箱率可能對應多個產品，那麼應該是產品一個表。裝箱率一個表，還有有一個表是用來存儲這兩者之間的關系。

『肆』 數據表設計考慮哪些問題

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。

一、選擇合適的語言與資料庫字元集。

在企業中部署資料庫的時候，首先需要在操作系統上安裝資料庫。而在安裝資料庫的時候，需要選擇安裝的語言環境。即是以中文狀態下安裝資料庫還是以英文狀態安裝資料庫。如在啟動安裝程序的時，可以利用/i language選項來指定安裝過程中所採用的語言。到目前為止，DB2資料庫已經支持很多種語言。那麼資料庫在安裝過程中，該採用什麼語言呢？筆者建議，只要資料庫管理員有一點英語基礎，最好能夠採用英文語言環境來進行安裝。雖然說現在DB2資料庫的中文語言環境已經設計的比較完善，但是筆者仍然擔心其有一些不知名的漏洞。為此筆者在安裝DB2資料庫的時候，基本上都採用的是英文語言環境來進行安裝。即將語言設置為「EN」，表示英文。提高DB2數據備份與恢復的效率。

另外如果DB2 資料庫中要保存英文以外的數據，或者說用戶會使用不同的字元集訪問資料庫時，還需要在資料庫安裝過程中選擇特定的資料庫字元集。DB2資料庫中的所有字元數據，包括數據字典中的數據，都是存儲在資料庫字元集中的。如果用戶使用不同的字元集訪問資料庫時，資料庫管理員就需要選擇包含所有這些用戶的字元集的超集。只有如此，才能夠確保系統能夠很方便的使用替代字元完成字元的轉換，從而提高資料庫的性能。如果用戶選擇的字元集不對，有可能會出現一些莫名其妙的問題。如一次用戶在安裝資料庫過程中，沒有選擇合適的字元集。雖然在使用的過程中，其存儲中文字元沒有問題。但是當對資料庫採取還原操作時，卻發現還原後的資料庫中有些原來是中文字元的地方，盡然出現了亂碼。這主要就是沒有選擇合適的字元集惹的禍。有時候如果字元集選擇不當的話，從外部數據源(如Excel表格)導入數據的時候，中文數據也會無法順利導入。所以，資料庫管理員在安裝資料庫的時候，需要根據實際企業，來選擇合適的字元集。

二、評估資料庫對象的大小、數量。

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。其實DB2 資料庫就好像一個倉庫，資料庫中的對象(如索引、數據表、表空間)等等就好像倉庫中的貨物。如果貨物比較少，那麼隨便放放，倉庫都顯得很空曠。貨物尋找起來也會很方便。但是如果貨物數量比較多、比較大，就必須要對其存儲空間進行合理規劃。只有如此才能夠讓倉庫的空間利用率達到最佳狀態。並且貨物的存放有序，在查找起來也特別的方便。筆者這里就以倉庫管理為例，說話該如何做好資料庫對象大小、數量等方便的評估，以及他們對於資料庫性能與穩定性的影響。

1、根據對象大小來規劃存儲空間。在倉庫貨物的擺放上，要根據貨物的大小來規劃存儲空間。或者說要首先防止大的貨物。只有如此空間的利用率才會最高。其實在規劃DB2對象的時候，也是如此。如某些表可能會包含的記錄比較多，屬於大表。此時資料庫管理員就需要考慮，是否將其放置在一個獨立的表空間或者硬碟空間上，以提高數據操作的性能。大表所對應的索引往往也是比較大的。為此在硬體條件允許的情況下，將索引表與數據表分別存放在不同的硬碟上，可以提高資料庫的性能。而對於一些比較小的對象(如數據表)，可以將它們存放在一個表空間中。其實這個表空間就好像倉庫中的一個個紙盒子。將小的對象放入到這個「紙盒子」中，不但不佔空間，而且也容易管理。

2、根據對象的使用頻率來規劃存放空間。在倉庫中擺放物品的時候，往往會把近期就要用到的貨物或者頻繁需要用到的東西放在倉庫門口或者容易拿到的地方。如此在拿這些貨物時就會比較便捷，也不會對其他貨物產生影響。對於DB2資料庫中的對象來說，也是這么一回事。可以將那些訪問量比較大的對象，如索引、數據表，存放在性能比較好的硬碟上或者單獨的硬碟中。此時訪問這些數據，就不會與其它對象產生I/O沖突，操作起來速度就會比較快。而將不怎麼用到的對象，存放在一起。由於他們不怎麼被用到，所以即使存放在性能比較低的硬碟上，其對資料庫性能產生的負面影響也是非常有限的。 在DB2資料庫裡面如何更新執行計劃

3、根據類別來存放資料庫對象。在倉庫中存放貨物的時候，還會對其進行分類。然後根據類別來進行存放。這有利於貨物的管理與檢索。其實在資料庫對象存儲空間設計時，也需要考慮這個因素。如現在應用軟體在設計的時候，很多都是根據模塊來設計。那麼在資料庫對象設計時，也需要根據這個模塊來設計存儲的空間。如將同一個模塊的資料庫對象存放在同一個表空間內。不過這可能會跟上面的兩個建立相違背。此時最好是在對象的命名上做文章。如可以根據模塊的不同，分別給資料庫對象取一個相同的前綴或者後綴。如即使同一塊模塊要用到多個表空間，此時就可以給表空間一個相同的前綴。如此在管理資料庫對象的時候，根據表空間的前綴就可以判斷其所屬的模塊了。如果再加上一個後綴來表示其資料庫對象的分類，那麼就更合理了。為此在管理資料庫對象的時候，要執行分類管理。不僅要從技術上對其進行分類，如分為索引、數據表、關鍵字等等。還需要從功能上進行分類，如按應用程序的模塊來進行分類等等。

三、設計好資料庫備份與還原的方案。

在資料庫交付生產使用之後，往往需要進行大量的測試。但是在測試過程中往往又會產生很多的垃圾數據。可是交給企業應用的，肯定是一個干凈的資料庫系統。為此在資料庫設計的時候，就需要想好如果減少測試過程中的垃圾數據。或者採取什麼樣的方式來實現在交互時自動清除垃圾數據的機制。

一般來說，想要一個資料庫備份與還原的方案，減少資料庫測試所產生的垃圾數據。如現在在給企業部署資料庫的時候，往往是先安裝一個干凈的資料庫系統。當然字元集這些需要預先設置好。然後再利用資料庫還原功能將預先定義好的資料庫模型還原出來。

另外有些時候需要兩個方案互為補充。如在資料庫初始化的過程中，採用資料庫還原的方式來創建資料庫對象。但是在應用軟體升級的時候，由於此時已經有了用戶的數據，為此不能夠在使用資料庫還原的方法。而是通過應用程序來執行某些sql代碼，來調整或者增加部分資料庫對象。無論採用哪一種方式，需要遵循的一個原則就是在給企業創建資料庫對象時要最大限度的減少測試。而要做到這一點，就是需要先在測試伺服器上創建對象並測試對象可用。然後直接將相關的SQL代碼在投入使用的資料庫伺服器上執行。

『伍』 我設計了一張資料庫商品表，但是怎麼統計商品每一天，每個月的銷售數量，

商品表應該只用作存儲商品基本信息，你要統計銷量就涉及到了交易，你可以再建一張交易流水表，交易流水表裡面（主鍵id、商品id、商品名稱、商品數量、出售日期）。你要統計銷量時，在交易流水表裡查詢指定時間內指定的商品就行了

『陸』 對mysql資料庫有深入了解的來，mysql如何設計多個含多種不同商品，且商品屬性不一樣的表

幫一樓的個哥們補充一下吧，你做兩個表
第一個表是商品表。包含商品id，商品名，品牌，商品型號，等等
第二個是商品信息表。欄位包括商品id，屬性英文名稱，屬性中文名稱，屬性值。
比如我有一個三星的電視
在第一個表裡面寫
id=1,商品名=三星電視，品牌=三星，商品型號=32XXXXX。。。。
第二個表裡面寫
id=1，屬性英文名：LCDTYPE，屬性中文名：液晶類型，屬性值：LED
id=1，屬性英文名：size，屬性中文名：液晶尺寸，屬性值：32
。。。。。。

『柒』 資料庫 商品會員折扣表怎麼設計

首先你有商品表吧，有會員等級表吧，你是按照會員等級去折扣的對吧。
你的商品表，增加欄位比如 會員折扣 欄位
你的會員等級表 增加折扣欄位 或者關聯折扣表
然後這個商品表中的 會員折扣欄位 和 會員等級表中的 會員關聯。。
然後你搜索商品表時 可以帶出 會員等級 對應的折扣了 。。然後根據折扣計算商品價格可以了。
大概想了一下應差不太多，不需要你後面說的那麼弄

『捌』 淘寶的資料庫中商品表是怎麼設計的

您好
3個表，一個放訂單，有訂單號、下單時間、下單客戶等信息。
另一個放訂單包含的商品，有商品id，折扣，數量。一個訂單可以包含一個或多個商品。
再一個表放送貨地址、發票、付款方式等亂七八糟信息。

僅供參考~

『玖』 請問我這個業務應該怎麼設計資料庫表

你這個主要區別就是：總庫商品價格和商家商品價格，要把這2個價格區分出來。
設計時，資料庫結構可以一樣，價格最好取兩個不同欄位名稱。
商家從總庫下載商品數據，保存到商家自己的資料庫，只能修改商家價格，其它禁止修改，這樣就只會價格不同，其它和總庫一致。

『拾』 如何設計動態欄位的產品資料庫表

可以採用四種技術：

動態增加資料庫表欄位
預留足夠的空白欄位，運行時作動態影射
用xml格式保存在單欄位里
改列為行，用另外一個表存放定製欄位

【一】

現在我們來分析一下四種技術的優劣，不過首先可以排除的是第一點動態增加欄位的方法，因為在實際操作時候幾乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不討論就排除。剩下後三點。

【二】

先來討論預留空白欄位的方法，基本原理就是在資料庫表設計的時候加入一些多餘的欄位，看下面的代碼：

CREATE TABLE Sample(
name varchar(12),
field0 varchar(1),
field1 varchar(1),
fieldN varchar(1)
}

然後看實際運行時候的需要，動態分配欄位給系統使用，也許需要一個這樣的結構來描述分配情況：

public class Available
{
public int CurrentUnusedFieldNumber;
public Hashtable FieldToRealName;
}

也許某一時刻的數據狀況是這樣的： CurrentUnusedFieldNumber=3,
哈西表FieldToRealName包含內容是("field0"="SomeId", "field1"="AnyName",
"field2=IsOk")
現在的問題是如果要配合Hibernate，如何來處理？以上段的數據使用狀況為例子，如果我們的類定義是這樣：
public class Entity01
{
public string Name;
public string SomeId;
public string AnyName;
public bool IsOk;
}

也許只需要修改一下xxx.hbm.xml，把 SomeId 和 field0
做成對應就ok了。但是在運行時我們怎麼知道會有這樣的類定義？除非我們做動態代碼生成，自動編譯也許可以，但是問題也許就到其他方面去了；如果我們不用動態定義，那麼類就只能是這樣：
public class Entity01
{
public string Name;
public Hashtable ExtraFieldAndValues;
}

使用的時候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss")
的方式來引用，也許這樣是修改最少的了，但是問題是Hibernate不支持這樣的方法。

【三】
再來討論單欄位存儲的方法，我們使用這樣的資料庫表定義
CREATE TABLE Sample
(
Name varchar(12),
Xml CLOB(102400) // 僅作說明而已
)

然後對應這樣的類定義
public class Entity01
{
public string Name;
public string Xml;
public Hashtable ExtraNameAndValueFromXml;
}

我們的代碼就可以這樣使用：string id =
entity01.ExtraNameAndValueFromXml.getValue("SomeId")
了。這樣解決看起來很不錯，不僅不需要Available表，而且看起來Hibernate對它的支持也很完美，但是致命的問題在於：如果保持高效的查詢？除非資料庫系統本身對此有支持，否則就只能用低效的substring或者like做查詢，這在大批量數據中根本就不可行。
是不是折衷一下，把兩種方法的優點和起來？問題有來了：怎麼保持兩者之間數據的同步？難道要我們用存儲過程去解析xml內容？
所以，一個兩難的問題，需要我們認真去解決。我們通過認真的需求分析，也許可以減少可變欄位的數量，但是只要有一個可變欄位或者可變的可能性存在，我們始終要去解決這個兩難的問題。
期待繼續討論。

【四】
還有一種方法就是改列為行，用另外一個表存放擴展欄位，定義可以如下：
CREATE
TABLE SampleFields
(
idSample Integer,
fieldName varchar(30),
fieldValue varchar(100)
)
其中idSample關聯到Sample表的id欄位（我沒有寫出來）。這樣的話，Hibernate很容易支持，也可以支持Sql的查詢，而且可以支持把內容放到Hashtable中去，看起來是目前最好的方式了。但是在大容量數據的時候，SampleFields表的數據會是主表數據量的N倍（看定製的欄位數目多少而定），同樣存在有很嚴重的性能問題。