这部分的设计必然少不了会有商品、货品、规格、规格值表。
先说下我对四个表之间关系设计:
商品与货品是一对多的关系。
规格与规格值是一对多的关系。
就这两种关系,关系很清晰,其实我刚开始的设计是这样的:
商品与货品是一对多的关系。
规格与规格值是一对多的关系。
商品与规格是多对多的关系。
商品与规格之间的中间表与规格值是多对多的关系。
货品与规格值是多对多的关系。
五种关系,看着都让人头疼,而这还是简单的情况下,比如客户要求商品发布时规格值名字是可手动修改的,那这时我们的"商品与规格之间的中间表与规格值是多对多的关系"就要修改它们的中间表了(中间表新增名称字段)。
真是剪不断,理不乱,我想了想于是决定使用字符串来保持它们之间的关系("保持它们之间的关系"可能说成"保存我方需要的对方的数据"更合理)。
让原本的规格与规格值表与商品表不直接关联(想象下规格就是规格,只是供商品发布时做为选项而存在的,而商品只是需要规格来完善自己,商品完善后规格的生和灭(从数据库中删除)与我无关了,这感觉很合理很正常),而是使用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的数据展示到页面即可。
怎么样,思路是不是清晰了,也许我的思路是错的,但是功能能够实现是最重要的。
如果你有更好的方式,请推荐给我,谢谢。
商品发布规格组合算法部分可参考这个:商品发布规格组合算法