作为最近开始计划的项目的一部分,我需要构建一个包含多个产品的数据库结构。举个例子,想想亚马逊的结构方式。它有几个类别,在这些类别中有几个子类别。
我的问题是,从概念上讲,我不确定如何构建数据库表。我曾想过为类别和子类别创建一个自引用表,但由于我计划在数据库中拥有各种各样的产品,我不知道是否应该将它们分组到一个名为“产品“或将它们全部放在单独的表中。
例如,厕所是一种产品,而电视可能是另一种产品。尽管它们具有不同的类别/子类别,但它们都是产品。通过将它们放在一个“产品”表中,它们将共享对它们都没有意义的属性。厕所不需要分辨率或显示尺寸的属性(除非它是一个非常特殊的厕所?)并且电视不需要座位尺寸属性。
我认为可以解决这个问题但是仍然将所有内容保存在一个表中会创建一堆NOT NULL属性,如果没有必要可能会丢失这些属性,但常识告诉我这个可能不是最好的办法。
所以在这一点上,我觉得我的真正问题是如何构建这个数据库及其表格,包括几个类别/子类别和不同类型的项目。我会创建一个电视桌和厕所桌吗?这一切将如何构建?这些问题通常是如何计划出来的?
由于
答案 0 :(得分:2)
通用产品表是一个很好的方法。每次有新类型的产品时,您都不希望在架构中创建新表。
与类别类似,自我引用表与父/子关系更好,因此您不必在每次需要新级别的子类别时创建新表。
您的产品表应包含所有产品中常见的信息。例如。名称和可能的价格(虽然如果您对单个产品有不同的价格,那么价格最好存储在另一个引用该产品的表中。)
如果您有一堆与每个产品的特征相关的其他信息,那么可以创建一个属性表和另一个引用该产品的每个属性值的表。
这是一个简单的示例模式:
答案 1 :(得分:0)
取决于多少产品。如果您只出售厕所和电视机,我会说继续为它们制作完全独立的桌子,但是如果您有100种不同的产品类型,所有这些都具有不同的属性,我可能会建议创建一个存储公共属性的产品表(它们所有都有成本,可能是大小)然后是产品类型表,为每种产品类型指定一组属性,然后是属性表来定义属性并拉出产品值表。
例如,拿一台索尼电视。这将是产品的价格和产品类型的链接,这将是电视。这将是一对多人加入所有电视所具有的属性,索尼电视将在每个属性的产品值中都有条目。这样,您就不必重新定义共享属性,因此当您开始销售其他具有解决方案的内容时,您只需将它们添加到产品类型中即可。
有意义吗?
答案 2 :(得分:0)
这更像是一个设计决策而不是其他任何东西。
这是我将表格分开的方式:
categories
(例如家庭)
sub_categories
(例如,浴室是家庭的外键)
products
(例如陶瓷马桶)
对于额外的属性,您可以直接在products表中存储这些属性,也可以创建另一个名为products_extra_attributes
的表,并在products
表中存储一个可选的NULL值,这将是一个外键指向关于单个产品的附加属性。
有意义吗?如果没有,我将在稍后进行编辑,因为我正在通过手机回答这个问题。