一、前言：
虽然说权限管理模块是最早接触的模块，但是公司不重视后台管理系统，所以权限管理也只是简单实现了菜单的控制，并没有太多的深入，而产品管理才是第一个真正实现的完整模块。
大大小小经历了三个项目，产品管理也是一直在不断更新完整中，从最开始直接将属性名作为不同产品区分的标识，到后面的完整规范的商品表设计，可以说，每一个新项目的，都是伴随着产品模块的再一次重构和改良。
二、 SPU、SKU
我们常说的，“货品”是指一种概念物品，这种物品并不是一个具体的实物，当它具备具体的属性、价格时，才是一种实物，也就是商品。“商品”就是库存中一个具体的实物。例如：iphone6，就是一种货品，但用户购买的并不是货品而是商品，也就是用户最终购买的可能是：金色-16G-移动版 iphone6。换句话来说，货品是一种产品的称谓（如iphone6），商品是用户购买的具体实物，具备特定的属性（如：金色-16G-移动版）。如果觉得这样理解还是比较混，那么忘记这两个概念，下面讲标准化的名称。
我们刚才说的iphone6，书面称谓叫“SPU” Standard Product Unit （标准化产品单元），它是最接近用户认知的产品单元，比如用户说，我想买个iphone4、iphone6、小米4，这些都是SPU，也就是用户普遍认知范围内的一种产品。然而在电商系统中只有SPU并没有什么卵用，用户购买时肯定要确定，需要什么颜色、多少G的，支持什么网络。所以，例如金色-16G-移动版 iphone6，就需要一个名称去规范它，这个名称叫“SKU” Stock Keeping Unit(库存单元)，换句话理解就是库存里面存的东西，库存里存在东西肯定是具体的某种规格的iphone6。
三、商品表设计
1、表结构
商品的表的类图我并没有画，刚好在csdn看到立心的表设计跟我差不多，所以直接用他的图来说，包括的上面spu和sku和介绍也是引用他，非常感谢。
具体如下：
这个产品表设计也是比较基本的，最近又加了抢购和限购，就暂时没加入这个表里。
上面是表设计是基于关系型数据库，而实际上我的数据库是mongo，所以在设计上稍微有点不同，
主要不同点如下：
1.品牌、分类、SPU我是做了三级联动，而图上品牌和分类是没有关系的；
2.由于mongo是文档类型数据库，于是我将产品属性和规格内嵌进了产品分类里面，如下：
产品SPU：其中pp存放产品属性，spec存放产品规格
3.sku之前也是内嵌在spu里面，但是后来考虑到购物车里面只需存放sku的id，而如果使用内嵌，那么还需要存放spu的id，这样购物车的业务方法处理产品时稍微麻烦点，不够简洁，后来干脆分开两张表。
4.规格设计不一样，我是在创建产品分类的是否先确定一个基本单位，例如衣服的基本单位是件，在添加规格时，如果我们要添加一个2件/盒，只需要在单位上输入盒，下拉框选择件，最后输入数量。
5.属性方面,其中属性值是数组，可以存放多个属性值，相同属性则替换或者保持不变
value则存放属性的属性值集合