http://www.cnblogs.com/leefreeman/p/4060227.html
http://www.cnblogs.com/leefreeman/p/4060227.html
商品模型的演化
在以前，那时CMS很流行，最常见的模型是栏目-文章模型。于是做电商的时候，自然就继承了这种一对多的关系。只是栏目变成了分类，文章变成了商品。商品也具备了独特的业务属性。现在很多电商网站上左侧的菜单，也就是这个分类。
后来我们慢慢发现一个问题，只有分类并不能适应所有的需求，比如nike鞋和nikeT恤，用户可能希望先看nike的所有商品，这个模型就不能满足。我们想在这个关系中，加入“品牌”概念。于是：
这样基本用户可以在首页上通过分类或者品牌找到自己想要的商品，也可以直接查看热门的商品和新上架的商品。但是问题也来了，用户在进入分类后，展示在用户面前的是很多很多商品，用户希望再通过筛选查询出更接近他目标的商品。于是优秀的产品设计师，设计出了类似这样的UI：
用户可以通过这些筛选条件进一步缩小自己的目标范围，那么问题又来了，这样的产品需求排在程序员面前，怎么去实现它？经过分析，我们找出了一个方法，我们知道商品之间的属性可能存在着较大的差别，比如牛仔裤它有版型、腰型、裤长等属性；而电脑它有CPU、显卡等属性，各类商品的属性是不同的。再进一步想，休闲裤也版型、腰型、裤长等属性；台式电脑或者笔记本电脑都有CPU、显卡等属性。所以我们得出：一个分类对应若干属性，而一个属性，对应若干属性选项，而一个具体商品又对应若干属性选项（例如具体一条牛仔裤，他的裤长：7分，裤型：直筒）。有点绕，仔细品味一下。
从图上可以看出，分类和属性的关系（例如：“牛仔裤”分类下有裤型、裤长、版型等属性）、属性和属性选项的关系（例如：裤长属性有长款、九分裤、七分裤的选项）、商品和属性选项的关系（例如某条牛仔裤的裤长是7分裤）。至此，我们知道一个商品的分类、品牌以及它有什么属性和对应的属性值。那么通过筛选条件，自然就可以查询出指定的商品。这里特别说一句，价格也是属性，不要设想用商品表中的价格字段去做计算。这不利于查询也增加了复杂度，让商家编辑人员用属性来设置并保证他的正确性。
有了这个模型，我们大概就可以看到以下界面（请不要太关注左边，重点在右边和下面）：
这个页面展示商品的所有信息，按照之前的设计好像都可以满足。但是我们似乎感觉错过了什么，在图上右边我们发现该商品当前的颜色和尺寸，并且允许用户可以选择其他的颜色和尺寸。这给我们带来了疑惑，这里的“颜色”和“尺寸”是什么，一件商品的不同颜色不同尺寸是算一个商品还是多个商品。经过思考后，我们发现我们混淆了两个概念——“商品”和“货品”。不同规格的货品作为独立的商品。比如一条裤子的有L尺寸、M尺寸、一个U盘有16G还是32G的，都是同样的货品，不同规格的商品。可以认为货品和商品是一对多的关系。弄清了这个概念，处理这个需求就容易多了，这里的“颜色”、“尺寸”我们就作为“规格”来处理，而红色、黑色；L号、M号我们视为规格的选项或者说规格值。一件货品对应若干规格，而具有某一规格值的货品就是商品。
好了，现在好像差不多了。基于这个模型可以满足基本的商品搜索、展示的需求。搜索引擎也可以根据这个模型数据生成对应的商品索引，达到准确搜索的目的。商品模块还会和其他模块一起协作，比如用户系统、订单系统、支付系统等。一般情况下我们会把商品业务独立出来做成“商品中心”的服务，集中处理商品查询、更新、发布等业务，支撑其他业务。
