这部分的设计必然少不了会有商品、货品、规格、规格值表。
先说下我对四个表之间关系设计：
商品与货品是一对多的关系。
规格与规格值是一对多的关系。
就这两种关系，关系很清晰，其实我刚开始的设计是这样的：
商品与货品是一对多的关系。
规格与规格值是一对多的关系。
商品与规格是多对多的关系。
商品与规格之间的中间表与规格值是多对多的关系。
货品与规格值是多对多的关系。
五种关系，看着都让人头疼，而这还是简单的情况下，比如客户要求商品发布时规格值名字是可手动修改的，那这时我们的"商品与规格之间的中间表与规格值是多对多的关系"就要修改它们的中间表了(中间表新增名称字段)。
真是剪不断，理不乱，我想了想于是决定使用字符串来保持它们之间的关系("保持它们之间的关系"可能说成"保存我方需要的对方的数据"更合理)。
让原本的规格与规格值表与商品表不直接关联(想象下规格就是规格，只是供商品发布时做为选项而存在的，而商品只是需要规格来完善自己，商品完善后规格的生和灭(从数据库中删除)与我无关了，这感觉很合理很正常)，而是使用json字符串保存用户所想要的规格数据，货品表也一样，不再与规格值关联，而是选择使用json字符串。
这么一来就得到刚开始说的那种只有两种关系了，下面说下商品与货品：
假设我们的商品规格是这样一个字段为productSpecs的json:[{id:0,name:颜色,solr:0,specValues:[{id:0,name:蓝色,pic:blue.jpg},{id:1,name:红色,pic:red.jpg}]},{id:1,name:尺码,solr:1,specValues:[{id:2,name:10},{id:3,name:20}]}]
假设我们的货品1规格值是这样一个goodsKeys的json:[{id:0},{id:2}],货品2规格值是这样一个json:[{id:0},{id:3}]
当用户浏览商城主页点击一个商品查看商品详情时，后台会查询对应的商品数据展示到详情页，别的数据就不说了，就说规格选项那块，比如选项如下表:
颜色
蓝色
红色
尺码
10
20
说下面之前，我们可以先想象一下每一个货品都有一把锁(goodsKeys)，等待着用户去解锁，而解锁的钥匙都在商品那里(productSpecs)。
关于上面那个表是如何出现的呢？假设我用JavaScript代码写个案例给你们看下:
//var productSpecs= [{id:0,name:颜色,solr:0,specValues:[{id:0,name:蓝色,pic:blue.jpg},{id:1,name:红色,pic:red.jpg}]},{id:1,name:尺码,solr:1,specValues:[{id:2,name:10},{id:3,name:20}]}]/*for(var i=0;i
productSpecs[i].id;
productSpecs[i].name;
for(var j=0;j
productSpecs[i].specValues[j].id;
productSpecs[i].specValues[j].name;
productSpecs[i].specValues[j].pic;
}
}*/
上面的代码我只写了取数据的部分，是因为这个编辑器不方便编码，其实只要取到了 数据，生成表格就很简单了，实际开发中这块应该是在动态页面中处理完成的，动态页面一般都有遍历列表的方式，比如jsp中的jstl等。
表格选项生成了，也梳理通了逻辑，那么剩下的其实很简单了，比如用户选择颜色：蓝色，尺码：10的一个货品，颜色蓝色id是0，尺码10id是2，那么我们后台就去货品表里查找goodsKeys相匹配的货品，通过比较我们发现货品1是匹配的，因为它的goodsKeys是[{id:0},{id:2}]，那么我们把货品1的数据展示到页面即可。
怎么样，思路是不是清晰了，也许我的思路是错的，但是功能能够实现是最重要的。
如果你有更好的方式，请推荐给我，谢谢。
商品发布规格组合算法部分可参考这个：商品发布规格组合算法
)
