前言
那个啥…前面发了2篇文章讲这个商品表的设计，后面越多需求浮出水面才发现设计依旧有问题，好吧，乐观一点，正如我博客的标题一样，我在进化…^_^
为什么要这样设计
先说几个需求，看看您现在是如何去实现：
一个用户来到我们网站,在前台页面,
1.他要买洗发水，他进入了洗发水的类别，他想买带去屑止痒功效的500ml的洗发水，能否直接搜索出来所有品牌带这个功效属性是500ml的洗发水
2.接着他要买一件T恤，他想买V领，短袖的T恤，能否直接通过2个属性搜索出所有品牌的T恤展示给他
3.他进入一个T恤的详情页面，由于白色卖的比较好，所以白色会比其他颜色贵一些，所以他选择不同颜色+不同尺码的搭配，就会显示出不同的价格以及是否有库存
后台：
1.统计某些商品某种属性销量情况和库存，反馈给仓库部门及时备货，比如海飞丝去屑系列的250ml的洗发水在这个系列中卖的最好，300ml的其次。A品牌XX大衣红色XL时间段内的销量和库存量。
2.这个洗发水在做一个阶梯价销售，买2瓶便宜2块，买3瓶便宜5块，需要给出这种组合的销售量数据给策划人员来说明阶梯价销售对消费者的影响
3.A品牌T恤分圆领，V领，7分袖，短袖，统计圆领和V领销量情况供买手或者设计师参考大众比较接受什么设计，以备下一次的采购。
4.这一年做了几十个活动，每个活动做了很多单品的搭配组合销售，比如500ml某种洗发水+黄色的眼霜等，我们现在没有做数据仓库和数据分析，那么要求sql语句来得到那种单品的销量情况，让我们可以能得知策划者的搭配到达了什么样的效果。
甚至变态一点，我们要统计我们店得面膜的销售，我要知道撕拉型的面膜，水洗式面膜，睡眠免洗式面膜中带美白功能，带抗皱功能，带控油功能等哪种卖的好一些，怎么办呢？
顺便扯一句，根据商品放置在页面的位置，深度，销量可以分析出某些品牌商品不需要放置在重要位置，某些对于我们来说利润高一点，或者销量不是很理想的商品放在重要位置或者排序在前来提高用户浏览量进而提高购买率。
如果不设计属性，这种搜索是很难进行的！如果不分的这么彻底，比如ecshop或者nopecomerce,那么你无法针对每个SKU设置组合搭配的价格和数量以及商家编码和SN号。
上一篇设计出现的问题以及解决办法
在上一遍文章中，有比较大的问题没有解决:
1.商品录入编辑界面编码实现过于复杂
2.如何通过属性搜索
3.按现在属性值属性表设计无法做到，如果A品牌洗发水有去痒止屑功效，B品牌洗发水同样有这个系列，无法搜索具有去痒止屑功效属性的所有洗发水的销量，因为现在的属性名和属性值表是1：N的关系，应该是N:N的关系
解决问题1：最简单的实现商品的录入界面:
在这里，我把商品的品牌和系列这个麻烦的东西分开了，为什么分开：品牌和系列导致2个属性名表和属性值多级引用，在实际代码实现过程中也会增加很多代码，增加复杂性.由于项目原因，这里只做了父子及关系，您在设计的时候，这里应该是品牌一张表，系列是父子及，有第3张表记录品牌与系列的多对多关系。为什么呢，只有这样，才能满足比如A洗发水有去屑止痒系列，B洗发水同样也有这个系列，那么才能方便的统计出去屑止痒洗发水的总的销售情况！
解决问题2.通过属性搜索
1.首先说明这个SKU和属性如何存储
在添加一个商品的时候，在pg_items表中保持商品的基本信息.
pg_item_sku表中保存sku信息，这个sku信息用来实现页面上的选择颜色，尺码这种组合不同价格，或者洗发水选择不同毫升数不同价格。
pg_item_attr表中保存所有属性信息，包括每个SKU的属性拆分之后的信息，这样的话，保证能通过每种属性来搜索商品。
比如我要搜索带有滋润功能的200ml的沐浴露，那么我的语句就是：
|
1
2
3
4
5
|
SELECT DISTINCT(dbo.pg_items.item_id),pg_items.name FROM dbo.pg_item_attr paINNER JOIN dbo.pg_items ON pg_items.item_id = pa.itemidINNER JOIN pg_item_attr pa2 ON pa.itemid = pa2.itemid -- 组合WHERE pa.p_id=772167869 AND pa.v_id=1866712003AND pa2.p_id = 1419662919 AND pa2.v_id = 758727405 -- 组合 |
我的做法是，通过属性值ID和属性名ID的组合组合成上面的语句，有多条就组合多次,这里按照我们一般的情况，是不会说组合到级联10几次的，如果您觉得不靠谱，欢迎提出出您的看法。
解决问题3.统计相同特性的不同商品的销售情况
如通过洗发水功效，服装的花色，衣领的样式来分析特性的不同对销售的影响.要实现在属性名和属性值表的设计的时候，应该是有第三张关系映射记录表来记录多对多关系。我这里还是偷懒了，因为我是针对淘宝的系统，拉下的属性已经是把3张表打横成了2张表，正好不用自己做了。如果是自己做系统，那就得考虑加上关系映射表.
这样设计的缺点
1.实现复杂
2.需要商品维护人员对自己商店卖的各种商品的属性，注重的统计的方面有个比较清晰的认识，学习成本高一点
3.策划，业务人员必须理解这样的设计，才能结合系统给决策带来所需要的数据
我觉得程序员应该对业务的理解仅次于项目的策划人和需求分析人员甚至比他们对某些商业模式更为理解，深入行业，了解行业的点点滴滴，有敏锐的需求的嗅觉，那么才能做出好的程序。而且程序是为业务服务的，如果不深入了解业务，那么很多时候程序会偏掉，举一个简单的列子，现在某衣服做一个活动，上午是200块，下午是150块，在晚上是100块，那么这个价格变动带来的销量就能给活动策划者提供强有力的数据支撑，我们也能学到背后的商业模式，为什么要这样做，如何做！（赚人气，打造爆款，清仓等）不然就写几行代码，搞搞表关系，有什么意思？？其实里面的各种调调，比几行代码有意思太多了!