电商网站商品属性设计的问题?

plugin 发布于 2016/06/13 12:24
阅读 3K+
收藏 9

主要参考的是这几篇博客

http://www.cnblogs.com/mmmjiang13/archive/2011/04/21/1983079.html。

我有个问题,按博主的意思是,当我创建一个商品时,选择分类的最后一个子节点,比如手机。

这时候,要想商品的属性能动态扩展,即设计一张属性表, 把属性由横转列。那么,品牌,材质,尺寸等等都成为了属性表里的一行记录。

那么这么一来,好像用户创建一个商品,好像只要这个分类表和属性表就够了,还需要商品表吗? 像库存这种属性放在哪里呢

加载中
1
j
java_oschina

以手机为例:

品牌表

商品表 水果7, 水果7s  这些是商品

属性表 比如 屏幕尺寸, 分辨率, 电池大小, 是否支持NFC

规格表 这是重点, 比如 16G, 黑色; 64G, 黑色    这个价格肯定不同, 这是决定商品价格的重要参数

最小销售单元表 这个才是最终卖出去的真正的商品, 比如 水果7,16G, 黑色, 4000元. 一个最小销售单元对应多个规格; 比如: 16G, 黑色, 白色(假设颜色不同价格不同)

plugin
plugin
回复 @java_oschina : 你好,我想请问下,这里应该少了一个型号,因为spu概念,是要能唯一确定一个商品,在这里应该是类型+品牌+型号。把这个型号是单独建表,还是放到属性表里去。
j
java_oschina
回复 @plugin : 对,就是这么回事. 因为有些参数会决定价格. 我发的那个图是 一个线上项目的实际结构,当然,不是全部.
plugin
plugin
1.其实,这里的品牌表, 属性表,规格表,最小销售单元里,放的都是属性。只不过,规格表里放的是销售属性(规格,颜色啊)其他表里放的是一般属性(分辨率,屏幕尺寸)。我可以这样理解吗?
kingsfighter
kingsfighter
SKU就是你这个最小销售单元的概念。
3
j
java_oschina

刚才可以能没说清楚,我给你个简易的图.

j
java_oschina
回复 @plugin : 因为规格也是属性啊,比如16G, 64G 只是它属于特殊属性. 规格表里只是引用了普通属性表的id啊 普通属性表的字段中有一个就是判断是否是 规格
plugin
plugin
回复 @java_oschina :1. 那你这张图里为啥只有规格属性值表,是没有贴规格表吗? 而且,为什么规格属性值表为什么要关联商品级联属性表呢?
j
java_oschina
回复 @plugin : 颜色, 内存, 这些影响价格的属性放在 规格表中 一个最小销售单元对应可能有多个规格 比如: 6S, 黑色, 16G
plugin
plugin
回复 @曾建凯 : 请问一下, 他这里的颜色,和内存大小是影响最终的产品的价格的,这两个属性算是”销售属性” , 这两个属性是放在哪张表里的,我没明白。
曾建凯
曾建凯
不过这个还只是线上电商的商品模型数据,工业原料类的物料属性会更繁杂一些。
下一页
0
kingsfighter
kingsfighter
商品表是一个纽带,比如商品名称,商品ID。商品表关联起这些属性,如颜色,型号等等。
库存不是属性,库存是要单独设计表的。
0
kingsfighter
kingsfighter
我之前设计的商品模型,大概不到10张表吧,基本能涵盖目前已知的商品。
D
Deanna
方便发我一份吗?谢谢。1666071167 At qq.com
kingsfighter
kingsfighter
@干死it 现在手头没有,回去给你找找
干死it
干死it
你设计的有发表出来不,如果有,给个地址, 参考下, 刚好弄电商商品的设计
0
飘逸的逸
飘逸的逸

我的理解是,这样的设计其实是把关系: 

商品表(N:N)属性表 

转换成

商品表(1:N)商品属性关系表(N:1)属性表

就和Hibernate Many-To_Many使用关系表维护一样.

0
曾建凯
曾建凯

商品表肯定要,基础价格,商品名称、描述等等还是在商品表里面放着的,也就是商品的主属性。库存这种表,一般的做法,是商品ID对应一条库存的实物数据,来表示存在一个实际的库存。但是业务上,也有存在,一个库存ID,代表是一个库存包,表示的多件实物数据。具体看你库存系统的需求。但一般到库存的概念,就需要明确到具体的实物ID,每一个实物都有自己的ID。

曾建凯
曾建凯
回复 @bastetwang : 批次其实比较复杂,看系统设计要求了,具体到有入库批次以及供应商的生产批次,再具体一点还有渠道批次等,还是看系统要求设计吧。
bastetwang
bastetwang
回复 @游弋丶 : 没做过的人不知道批次这东西
曾建凯
曾建凯
回复 @kingsfighter : 我目前设计电商系统,价格还是基于商品的基础属性,活动可以调整,乃至彻底使活动期内的某个商品具有某个特殊的价格,直到活动结束为止。以及商品存在套餐的销售的,都是基于一个商品价格去演变。我看过几个电商系统的设计,多个价格的设定,对于统计并不好,我们指导运营人员,也是基于基础价格来进行折扣设定,而不去设定特殊价格。
游弋丶
有库存,肯定会有批次存在。
kingsfighter
kingsfighter
建议价格也是一套表,有促销活动等因素会影响价格,但是商品表可以有个基础参考价格,不做实际用途,只是展示。
0
曾建凯
曾建凯

好像没说清楚,库存肯定是额外的一个表,他有一个字段,叫做商品ID。来反应库存的这条数据到底是哪个商品。线上电商一般并不关注库存的问题,有100个某种商品,卖完为止,并不会有具体1、2两个商品之间的差异。

而在库存系统看问题,你有100个商品的库存,那么理论上,每一个实物库存都应该有一个独一无二的专属于他的id,你可以理解为是个人总得有名字。假定一个班有30个学生,在电商角度只关心总数是不是有30个,但是在库存系统,就需要知道这30个人每个人具体叫什么,状态如何,是否有破损,等等。再复杂一点,是不是退换货等等。

0
kingsfighter
kingsfighter
再复杂点,商品不是固定的, 他是根据不同场景而变化的,设计属性的时候要考虑到渠道(变化的,不一定是渠道)这个因素,商品的属性信息是随着这个渠道的变化而配套变化的。
曾建凯
曾建凯
其实数据层面展开的细节,要多少有多少,最终还是看他设计这个系统给什么用,并且最好的做法是遵照数据库的范式去进行表数据,不是为了性能,而是为了日后的可扩展性
0
景愿
景愿

理解以下两个名词,可以保你应对自如:

1. SKU - 每个商品最好有一个SKU表,库存是针对SKU的

2. 弹性域 - 建好弹性域,能适应所有商品类型的属性




kingsfighter
kingsfighter
赞一个,标准化的是这样设计的。
0
钛元素
钛元素
另外,请注意,商城扩展所需的部分,比如商品目前只有10个属性,但是预留5个空白属性,以后有可能会有的上
返回顶部
顶部