关于B2C官网产品分类属性解决方案思路

http://www.cnblogs.com/godzone/archive/2011/07/15/2107496.html

关于B2C官网产品分类属性解决方案思路

 

一：为什么要做分类多属性？

1、网站架构的清爽性，可维护性，分类搜索
在一些比较大型的B2C网站，会发现不同的类目下面都会有一些不同的选项
例如进入了红酒柜类目，我可以选择是 多少瓶的 ，电子的还是压缩机的 ，价格范围等
如果进入了搅拌机的类目，我可以选择多少转的，功率，产量多少等

但如果是传统的属性表结构的话，将是这样储存
产品表：
名称，产品编码，型号，瓶数，压缩机类型，价格，转速，功率，产量

这样做的话  每一个产品都记录着这么多的信息，而且很多信息都不是自己想要的
例如红酒柜的时候不需要转速的数据，搅拌机不需要压缩机类型的数据
则存在十分多的数据冗余，更可怕的是，我们的产品分类几百种，如果都按传统的设计方式去实现的话，则难以管理
而且在前台设计的时候也不好做，十分每一个分类的都要有一个专门的class ?明显这种设计不大科学
从系统的维护性来说是不可取的

2、数据对比的实现：

在太平洋电脑网里面有个很好的功能，就是导购对比功能，如图


在我们圣托的产品不同于凡客，和京东
我们更多的是属于非标准的产品，还不属于家喻户晓的大品牌，

共10多万个产品，且种类繁多
那如何才能让顾客快速的选择出符合自己的产品呢？
我们也许可以定下一些行业标准，例如什么参数的产品质量更好，更合适哪类人群使用···
这里如果有一个如太平洋的对比功能就好很多了

二、如何实现分类多属性
1、数据结构：
我们知道，我们的产品可以进行分类，从面向对象的角度来说，我们的子类应该是继承于父类的，例如男人继承于人类所以，男人应该拥有人类所有的属性。
so：
分类表中可以添加一个字段，记录在这分类中的属性名，用JSON序列化储存到表字段中，子级分类亦然。
如{'转速' ,'刀片工艺'}
因为 json可以转换为array，所以我们的属性集将成为array的格式，最终所属类目的产品的属性则为所属类目以及其所有父级分类的并集。
如果从数据结构来说，我们可能会考虑得更严谨一些，不是转化为array而是一个tree里面
并在产品表中添加一个命名为ex_attr的字段名，对应属性集中的每一个属性，并以json的格式进行储存入表中。
例如{'转速':'10000/m','刀片工艺':'0.5mm'}

当然如果我们的类目想更多的功能，显示的更独特性的话 我们的json格式就可以储存为
[{"type":"int","display_style":"bar","title":"转速"},{"type":"string","display_style":"string","title":"刀片工艺"}]
json可以直接转化为tree 和 tree_item
发到园区，也是为了大家能拍拍砖，给点意见 谢谢
当然，这种设计还是一种思想。 希望这种思想能在下一版的系统改进中实现出来

#1楼 [ 楼主]  2011-07-15 15:43 |  肖希明   

很多地方比较跳跃性，也是考虑到大家的水平应该懂得我在讲什么

支持(0) 反对(0)

  

#2楼   2011-07-15 16:38 |  沉默杨仔   

云里雾里.没看懂.

支持(0) 反对(0)

  

#3楼   2011-07-15 16:49 |  IT鸟   

搜索的时候方便吗?

支持(0) 反对(0)

  

#4楼 [ 楼主]  2011-07-15 17:04 |  肖希明   

@IT鸟
这也是我考虑的问题之一
我的打算是这也解决这个问题的：
例如我要搜索转速为10000/m 的产品
那么我搜索的时候则会用 like "%'转速':'10000/m'%" 这样的语句，当然，这样的解决方案并不是无敌的，例如我要搜索转速在10000以上的话
这个设计就有点困难了，更多可以用在枚举型或者字符型的数据里面

支持(0) 反对(0)

  

#5楼   2011-07-15 17:09 |  IT鸟   

所有属性一个表,在产品总表里面可以in(1,2,3...)

支持(0) 反对(0)

  

#6楼 [ 楼主]  2011-07-15 17:18 |  肖希明   

@IT鸟
不是很理解您的意思，您是指用数组储存所有属性的编号吗，存储在产品表里面？
关于上文
还有就是关于公共属性的提取，我们都知道，一个产品都有价格，重量，尺寸 等通用的属性，那这些属性就不用用这种麻烦的方式去储存，而是用传统的方式，提高效率并减少存储空间

支持(0) 反对(0)

  

#7楼   2011-07-15 18:29 |  沈融兴   

很多开源的商场系统可以借鉴的....我研究了很长一段时间的ecshop产品属性表...说实话...做这个真的挺繁琐的...

支持(0) 反对(0)

  

#8楼   2011-07-15 18:42 |  redspear   

常用的不都是变列为行吗，这种情况可以借鉴博客系统的文章表和tag表的设计模式。用json，和用序列化字段没有什么区别，查询时候你就悲剧了。

支持(0) 反对(0)

  

#9楼   2011-07-16 13:57 |  ie421   

我这有一个成熟的方案，可以解决阁下的问题：思路如下：采用运行时自定义类型，自动生成表的方式。如自定一个产品的基类，存放公共的属性，如果需要定义特别类型的子类，则采用自定类型属性的方式，并自动生成子类的数据表来存放，这样这个特别的子类的数据就分别存放在两个表，一个为产品基类表和特殊子类表。在查询时，需要用到自定义结构查询体系，将这两个表联合起来查询，并返回所有数据。

这方案的好处是：可以自定义各种类型的属性，并且每一个类型都有特定的表来存放，每一个属性都有唯一的字段来存储，在查询，排序等功能非常方便。

不足的地方（或者叫难点）：每定义一个子类都需要生成一数据表，需要额外的代码来维护子类的属性列表和数据表的生成，在查询时，由于是运行时生成的Table，固查询方面也需要一个自定义查询框架来查询。每一种类型会生成一个表，会导致一个DB中产生很多自定自定义的Table（会非常之多，有好几百个，取决于系统中的类型的多少），有些公司不允许这种搞法，特别是DBA的反对。

总的来讲：这个方案就是运行时设计方式。其实整体技术难度并不大，我用这个方案已做了好几个项目的应用。如ERP系统的物料主档（不同类型的物料主档有不同的属性，显示的物料列表也显示不同的字段，可排序等，可按自定义字段来模糊或精确查询）。档案馆系统的文档类型。SRM系统的采购定单，报价单等（不同类型的物料，显示不同属性的采购规格和报价规格等）等等。

感兴趣的朋友可以和我来交流一下。
QQ:247430254 (请注明：自定义类型结构交流)
E-Mail:ie421@163.com