2009-10-19 73 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将会很痛苦。“

如果属性都不尽相同的数据类型,则属性,属性代表不可能是普遍的。

相关问题