如果是针对特定的商品,比如手机,有颜色、内存容量、版本这样的属性,建表的时候固定死几个字段就可以;
如果既有手机,又有电脑(属性字段和手机的不一样),笨办法是,你建的字段A\B\C\D在不同产品类型下有不同的中文含义,有点多态的感觉;
当然,我相信以上都不是好办法,因为这种方式耦合度太深,如果我们要新增一个数码相机,岂不是又要做一次对应? 而且,属性需要变化的时候,又会引起一连串的连锁反应。
也就得出一个结论:属性字段有必要做重新设计。
首先来分析一下,属性字段从哪里来?
这还不简单,肯定是确定一个类目的时候,我们后台要预设好的,恩,也就是说你要在后台新增数码相机这个商品大类的时候,你要新建一系列字段,诸如:搭配的镜头、像素、色彩等内容,也就是说这部分是人工添加的,需求是需要我们做出一个可伸缩的,今天可能是三个属性,明天可能需要在后台额外增加一个,而不需要去直接修改程序。
那我们新建表:主键、属性的中文名称、属性的英文名称、对应的商品类的编号;
然后根据商品添加报价,这时候就要进行交叉了,概率论的计算方式,可能的报价有很多种:三种颜色、两种内存容量、三种运营商版本,提问:如果全部填满,会有多少种可能的报价呢?
——————————
这是一种方法,另外还可以尝试用序列化的方式把属性内容存放在一起,或者用nosql的理念设计。
拙见仅供参考