页面属性的编程实现可以参考这里。SKU存放在产品SKU表中，按我们的实际需求增加修改字段，比如我的表中多了ProductCode和BarCode字段，SKU的属性会拆分后存入产品基本属性值表，便于搜索或统计等需求。商品的基本属性全部打横存入商品的基本属性表中，那么SKU表的存储如下：

那么这个item是4013的产品在基本属性值表中的数据存储如下：

 这里我是把所有的属性都打成一条一条存储在这个表中，那么能满足我们在日常业务的属性搜索，统计等需求。按属性搜索，这里必须要注意以下几点：

    1.不可能所有的属性都开放给用户或者我们的客户进行搜索，所以我们会在属性名表中有个字段（是否搜索字段）来人工控制哪些属性是搜索属性

    2.基本属性是同一个宝贝下面所有SKU都共有的，SKU属性是单个SKU独有的，所以搜索的时候还必须分清楚销售属性（销售属性组成SKU）和基本属性。

    3.属性图片的存储我并没有设计，因为我们是做快消品，没有这个需求。但是，如果我做的话我还会是在基本属性值表中加上”是否图片属性，是否使用默认图片，图片URL“3个字段来记录颜色属性。做属性搜索的时候比较方便。

    4.产品通过关键字搜索和属性搜索是分开的，两种搜索并不是一种解决方式，比如淘宝，在首页的搜索框是通过分词匹配宝贝标题的关键字，通过关键字的匹配程度，店铺的dsr评分权重来决定搜索结果，而属性搜索的时候则是匹配满足属性条件的宝贝。那属性又分第1点和第2点，所以还是挺麻烦的。

 

那到了这里产品的存储已经说完了，其它的运费什么的，就懒得说了。

 

这里你会发现有打包品表，打包品子表，最终商品表，商品变更记录表。这里需要详细说明一下。

 
首先说一下打包品概念：

打包品：为了各种运营上的需求，很多时候我们会人为的把多个SKU组合成一个商品进行组合销售，我们在淘宝购物的时候，经常会看到这样的情况，A产品+B产品组合销售，AB的组合在淘宝上面表现为一个宝贝，你看看这里或者这里或者这里，这些就是拉。这种销售数据在订单里表现是一个淘宝商品，但是我们要做库存管理，数据分析等需要拆分出来。这是必须考虑的！

PS：有那种出厂打包品，比如一个包装盒里面有香皂，有沐浴露，但是它们本身就是一个SKU，出厂就这样，所以不能和打包品混为一谈。

 

 

由于我们运营上的需要，我们可能卖单个SKU，也可能卖多个SKU的组合，那么在我这里把单个SKU和多个SKU组合都看成打包品，单个的SKU打包品它的子项只有它自己，这样做的好处是，系统中只需要一种方式来处理这种关系。在打包品表中通过类型来区分。

这里有一个关键问题要注意，我们在出售商品过程中，价格是可能会随时人工或者系统来干预变化的，比如产品A标题叫B洗发水+C护发素直降20元，但是我们根据实际的流量和转换率价格可以上下浮动，那么我们就要及时的调整价格，所以我们的标题，价格都需要进行更改，这里牵涉2个问题，我们是新建一个打包品或者我们是另外放在最终商品表，我们就需要修改对应的标题和价格，同时呢，在商品变更记录表中记录添加一个上次修改的备份，作为我们对不同价格的转换率的一个分析基础数据。第二个问题就是由于修改了打包品或者创建了新的打包品（SKU子项，SKU数量一样）价格，那么对应的分配到每个具体SKU的价格发生了变化，这里如果是新建了打包品就没问题，但是如果是修改打包品，那么我们对打包品SKU子项的价格就必须通过相应的公式进行计算。比如A+B+C今天是100元，A是30，B是50，C是20,如果价格变成了90或者110，那么对应到具体的子项价格也需要更改，因为很经常的需求就是统计某产品或者某SKU的销售量和销售额。

所以最终是我们网站上是出售打包品还是最终产品，是每次新建打包品还是修改，这要看自己权衡。但是商品的价格变更是一定要记录的。一是留备份，二是分析价格对销售的影响等等。

 

 
这样设计遇到的问题

1.起初产品维护人员意见很大，觉得很复杂，工作量很大。因为这种结构需要维护人员维护属性，并且需要他们懂一些专业知识和熟悉整个流程，各种名词搞得他们头晕，后面甚至出现了相当大的负面抵触情绪。这个没办法，因为我们这个不是网站，不是说让你简单的舒服的就能添加一个商品，这个需要掌握分类-产品-属性-打包品之间的业务关系以及这样维护的好处。解决办法：1.慢慢沟通，说明增加的工作量是为了他们在出复杂的报表的时候不需要手动去进行筛选，而且基础数据维护好了，一劳永逸。2.一定要培训好产品维护人员，让他们在有相关业务背景人员指导下能清晰的分清楚属性的意义，以及根据业务规则维护好属性基础表和录入产品等信息。

2.由于一开始数据的关联检查机制没做好，导致后面乱了很多数据，所以在后面又来花时间检验数据和建立起相应的检查机制，浪费了很多时间。