sku商品表设计

产品表product

p_ID int 主键

p_Name varchar

p_Dic varchar //产品描述

p_Picture varchar//产品图在硬盘中的储存路径

装配过程表Flow

f_ID int 主键

f_Name varchar

f_Picture varchar//产品装配图在硬盘中的储存路径

p_ID int //外键

主类： 主类不能以大概念的分类来分，如衣服、食品...

这样范围太泛了，不好往下定位子类和子类的 规格 和 参数 ，

大类最好往下再细分，如：男装、女装、酒水饮料...

男装 >休闲裤、牛仔裤、男士外套...

酒水饮料 >酒、插、冲剂

子类：子类决定规格明细的分类，如酒按照品种...

茶按照净含量、类别...

酒 >>品种

茶 >>净含量、类别

冲剂 >>类别

在京东的子类下面还有一个 孙类 的细分，

如：男士外套 >>>毛衣/针织衫、西服、卫衣...

针对孙类，再进行对应的产品参数划分：品牌、颜色、款式、分类、屏幕尺寸、版型、下摆设计、风格、袖长...

如：毛衣 >>>>袖长、风格...

牛仔外套 >>>>版型、下摆设计

因此商品的分类配置，应该是由专门的产品经理和市场调研人员进行配置好；

后续上架商品的人，可以直接在配置好的分类下勾选

规格：净含量、类别、品种、颜色、尺码... （注意这里的尺码跟下面的尺码不一样的，下面尺码用于分类下的筛选）

specifications

参数：品牌、颜色、款式、分类、屏幕尺寸、版型、下摆设计、风格、袖长...

parameter

品牌：金骏眉、功夫红茶、菊花茶、普洱...

等级：一级、二级、三级、其他、特级...

包装：

盒装：袋装、罐装、礼盒装、纸包装...

Demo:

男装 >男士外套 >>卫衣(中国李宁卫衣)

分类表：

商品分类编号，分类名称，父分类编号

1, 男装，0

2，男士外套，1

3，毛衣，2,

4，女装，0

5，酒水饮料，0

6，女士外套，4，

7，西服，2，

8，卫衣，2

规格名：

规格编号，规格名，商品分类编号，父属性编号

1，颜色，1，0，（男装）

2，尺码，1，0，（男装）

3，净含量，5，0，

4，类别，5，0，

5，品种，5，0，

6，颜色，4，0，（女装）

7，尺码，4，0，（女装）

规格值

规格值编号, 规格值, 规格名编号

1，黑色，1

2，白色，1，

3，s，2，

4，x，2，

5，m，2，

商品表:

商品编号, 商品名称, 商品分类编号, SPU销量, 评论数，上架时间（立即上架、暂不上架、自定义上架时间）[ 商品轮播图，商品描述图，商品简介，商品关键字，商品是否推荐，商品是否新品，商品点击数， SPU下单数]

1，中国李宁卫衣，8，0，0

商品和规格关系表:

自增编号, 商品编号, 规格名编号, 规格值编号

1，1，1，1 （中国李宁(编号1)卫衣颜色黑色）

2，1，1，2 （中国李宁(编号1)卫衣颜色白色）

3，1，2，3 （中国李宁(编号1)卫衣尺寸s）

4，1，2，4 （中国李宁(编号1)卫衣尺寸x）

4，1，2，5 （中国李宁(编号1)卫衣尺寸m）

sku表（库存表）

SKU编号, 商品编号, SKU属性, 价格, 库存, SKU销量

1，1，[1:1,2:3]，199，20，0

商品和规格筛选表:

商品编号, 商品具有的属性值编号

1, [1,2,3,4,5]

用SQL全文检索实现筛选:

select * from 商品表

inner join 商品和规格筛选表

on 商品表.商品编号 = 商品和规格筛选表.商品编号

where 商品表.商品分类编号 = 8

and 商品和规格筛选表.商品具有的属性值编号 MATCH '1 3'

order by 商品表.评论数 DESC LIMIT 10 OFFSET 20

商品搜索表:

商品编号, 商品标题和内容

1, [无需词典,二元分词]

用SQL全文检索实现搜索.

正因为商品列表页相较于其他页面会显得有些拥挤，因此更应该抱着在限制的区域范围内展现最有用的信息的心态来设计网页。正在浏览商品列表页的用户也许对商品的细节描述并不是很在意，此时的浏览模式更偏于走马观花，因此，简单扼要的图片、商品名称，以及价格说明就已经能够满足用户在该页中的需求了。

2.鼠标悬停时产生交互效果

很多网站都会忽略鼠标悬停时应该产生的交互效果，其中也不乏一些知名电商。虽然只是一个很小的效果，但它存在的意义却远不仅如此，甚至承载了一份网站与用户之间的互动和反馈。

3.出现适量的附加信息

刚才提到了商品列表页应该尽量做到简单简洁，但在此基础上适量的增加一些对用户挑选商品有帮助的附加信息可以起到锦上添花的作用。

4.始终带给用户指引

可能很多电商网站都认为，当用户在商品列表页面停留就意味着即将找到自己需要的商品。而现实却告诉我们，用户很可能在不断翻页的过程中会不知不觉的改变了之前的目标商品，因此，网站应该始终为用户提供指引，带给他们明确的方向感。

5.设置相关推荐，促成更多消费

用一种商品推动另一种商品的销售，这是电子商务网站中的惯用营销手法，但这样的方式如果运用的太过生硬用户一定不领情，网站应该试着用柔和的方式传达相同的意思。

6.扫清页面死角　

页面中的每一个区域都有它的价值和意义，可能只是用户视觉的感知程度不同而已，只要做好布局，页面死角可以变得不存在。

商品列表页的死角多见于页面侧边和底部，而京东将这两片区域使用为其他产品的推广途径，比如销量排行和商品精选等。

7.用特色商品激发购物欲　

如果你觉得特色主推性质的商品只能放在网站首页你就错了，首页首屏的确是整个网站最佳的宣传黄金位置，但所得到的效果却不一定是最理想的，根据商品的类型安排布局才能达到事半功倍的效果。

8.吸引人的商品活动尽量置后

中国有句谚语，“好戏总在后头”，这句话也同样适用于电商商品列表页的设计中。把相对吸引人或是目的性强的商品活动放在偏后一点的位置，有利于整个网站的运营。

9.减少操作步骤

在商品列表页中，力所能及的步骤减少只有从商品加入购物车开始着手。但在此之前的大前提是商品信息展现的足够全面和完整，要在小区域内表达出所有内容也的确是一件比较困难的事。

10.从众效应

从众心理是网上购物人群的普遍状态，因此，买过该商品的顾客对此做出的评价对于用户来说很有说服力，商家可以利用这一点在网页的设计上做出一些小改变。

手表在这个时期不单单是时长的代表，也是时尚的代表。手表在搭配层面都是五彩缤纷多种多样，绚丽多姿，适合自己的手表搭配到合适的服饰或设计风格上面给总体搭配大大加分，具有锦上添花的功效。提到手表搭配就不能不提及浪琴手表了，不论是浪琴男表，或是浪琴女表，每一个系列都是有自身特有的含义和风韵，在和衣服裤子的搭配层面也有目共睹。近期浪琴女表的新产品心月系列产品以浪漫的爱情喻意火出了圈，遭受任敏，颖宝等女明星的亲睐，下边我便以浪琴女表新产品心月系列产品为我们浅谈一下手表和穿衣服搭配中间的“小心思”。

心月女生在使用心月系列产品手表去搭配时，假如自身一直以来的穿着打扮和性格特点是展现自我热情的那样挑选心月鲜红色款会更为合乎自身的穿衣搭配特点；而个人性格和穿衣服特点是偏温柔风的，平常也较为温润如玉，就能选心月系列产品的深蓝色款会更为适合自己的；针对较为性格开朗，朝气蓬勃与朝气的极品女神商品而言，挑选翠绿色来映衬自身的日常穿衣搭配会愈发的突显自己的风格特点。总得来说，言而总而言之手表的搭配要融合自个的穿搭风格和个人性格特点来选取，那样才能让手表给全部人的风格锦上添花，画龙点睛。

浪琴手表不但在制做技术上或是在含义喻意上面走在社会最前沿，此次新产品心月系列产品也是赋予了传送心动信号的含义，可是比含义更为高端的必买理由是浪琴女表的心月系列产品多种颜色的制定在搭配上可谓是达到了炉火纯青，能够达到每个人各种各样搭配要求。继承传统式造表加工工艺，全新升级浪琴手表心月系列产品手表配备石英机芯，3时位设定日期表明窗，6时部位设精致月相表明，在精确离开时中体会月相变化的烂漫。手表表壳表带造型设计撷取月亮的柔和线框，精美圆滑的轮廓线与月相相得益彰，寄予事事顺心的幸福祈福，让柔美诗意在手腕上运转。精刚手表链与手表表壳表带相辅相成，产生舒服配戴感受，阐释现代女性的多方面雅致。

浪琴手表心月系列产品月相手表，新增加草绿色仪表盘，仪表盘经重新设计，传统的罗马字母，选用不规律系统分区方法展现，增加浪漫派的诗情画意艺术美。仪表盘选用不一样打磨抛光加工工艺，在太阳纹和磨纱中转换，展现多种层次感的亮丽光泽度。精美圆滑的手表表壳表带，撷取月亮的柔和线框，3时位设定日期表明窗，6时部位设月相表明窗，让柔美诗意在手腕上运转。搭配精刚手表链，与手表表壳表带相辅相成，产生舒服配戴感受，阐释现代女性的多方面雅致。

动态增加数据库表字段

预留足够的空白字段，运行时作动态影射

用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倍（看定制的字段数目多少而定），同样存在有很严重的性能问题。