2009-10-19 50 views
2

我正在爲供應商設計基本的庫存系統。
他們有許多不同的產品類別。
每個產品類別都有很多不同的屬性。數據庫設計 - 具有屬性的多類產品

A-x1,x2,x3,a1,a2,a3;
B-x1,x2,x3,b1,b2,b3,b4;
C-x1,x2,x3,c1,c2;

Laptop - Make, Price, Quantity, Processor, OS, Hard drive, Memory, Video Card etc 
Monitor - Make, Price, Quantity, Size, ContrastRatio, Resolution etc 
Server - Make, Price, Quantity, Processor, OS, Memory, Netowrking etc 

設計1:每個類別的不同表格。
設計2:公共表,屬性表。

什麼是最好的方法?

+0

你可能要重新狀態多一點真實世界的例子的問題。這是有點難以遵循 – JohnFx 2009-10-19 18:54:54

+0

你好JohnFx: 下面是一個例子: 筆記本電腦 - 製作,價格,數量,處理器,操作系統,硬盤,內存,顯卡等 監視器 - 讓,價格,數量,尺寸。 ,對比度,分辨率等 服務器 - 品牌,價格,數量,處理器,操作系統,內存,Netowrking等 – Natkeeran 2009-10-19 19:34:45

+0

@Natkeeran:請更新您的問題。不要評論你的問題。請更新它。 – 2009-10-19 19:37:10

回答

0

與第二個選項一起需要爲每個查詢進行連接,使用第一個選項將使查詢更難,因爲您將有許多表,現在必須決定查詢哪個表。我更喜歡第二種選擇,因爲從長遠來看,應用程序開發更簡單(但我可能很懶)。

3

絕對不希望不必要地增加模式(奧卡姆的規則,你知道)。排列多個一對多關係的標準方法是簡單地在中間表:

Products 
-------- 
ProductID 


Categories 
---------- 
CategoryID 


ProductCategories 
----------------- 
ProductID 
CategoryID 

它簡單易懂的查詢和行業最佳實踐。

+0

是的,就像他說的。產品可以屬於很多類別,反之亦然,等等。好東西。 [產品] - > [產品類別] < - [類別] – Tim 2009-10-19 19:20:22

0

通常的設計是最常用屬性的常見表格,然後是每個類別的子表格以及該類別的特殊屬性。

或者,您可以使用實體值結構,但通常不推薦使用它,因爲它很難查詢並且不能很好地擴展。

您需要做的一件事是人們經常忘記的是將購買時的價格存儲在庫存物品的記錄中(我會考慮其中一個常見屬性)。如果您依靠產品表中的價格,它將隨着價格的變化而更新,但出於會計目的而不是該項目支付的價格。當您接受審計或稅務時間時,這可能非常糟糕!

+0

/我不寒而慄你不得不提醒我關於價格點,折扣,免稅... – 2009-10-19 19:31:25

+0

我也不寒而慄,我不得不修復一個庫存數據庫,錯誤地使用產品表來獲得價格。 – HLGEM 2009-10-19 20:06:30

1

如果不知道更多關於您的域的信息,我會傾向於使用設計2.這將限制表的數量,並對多個類別的不同屬性進行查詢,使其更具可讀性和效率。

如果您有少量類型爲靜態且每個屬性不同的設計,則值得考慮設計1。如果是這種情況,您仍然可以通過創建屬性字典表來使用設計2。在這裏,您將擁有一個包含屬性屬性鍵/屬性名稱對的表。然後你的類別表可以包含類別ID,屬性ID,屬性值列。如果所有屬性都具有相同的數據類型,但如果它們不具有相同的數據類型,則可能會出現尷尬。

1

與設計1一起使用,每個類別都有不同的表格。

如果屬性不是全部相同的數據類型,設計2將會很痛苦。如果不是,它會強制你將它們全部存儲爲字符串,並寫出很多鑄造代碼。這也阻止了簡單的數據庫級數據類型驗證。

+1

這確實取決於OP的要求。如果OP期望類別的類別和數據類型數量大不相同,那麼完全拋棄關係模型並使用CouchDB可能是一個好主意。 – Juliet 2009-10-19 19:34:34

+0

CouchDB的+1,但我想這可能不在他/她的控制之下。 – JohnFx 2009-10-19 20:26:37

0

「如果屬性不是全部相同的數據類型,設計2將會很痛苦。「

如果屬性都不盡相同的數據類型,則屬性,屬性代表不可能是普遍的。