商品规格分析 · php笔记

商品规格的设计还需要考虑，当U规格更新，添加，删除时，会对商品，购物车有什么影响。更新规格和商品时修改了SpecGoodsPrice表。 tpshop更新规格时并没有修改购物车，更新商品时只修改购物车spec_key等于''的数据，也就是删除规格暂时不会影响购物车，购物车还看得到原先的旧的商品数据。但是当下单时，由于购物车数据有spec_key，由于使用 ~~~ getGoodNum($val['goods_id'], $val['spec_key']); /** * 获取商品库存 * @param type $goods_id 商品id * @param type $key 库存 key */ function getGoodNum($goods_id, $key) { if (!empty($key)) { return M("SpecGoodsPrice")->where("goods_id = $goods_id and `key` = '$key'")->getField('store_count'); } else { return M("Goods")->where("goods_id = $goods_id")->getField('store_count'); } } ~~~ 获取商品，所以SpecGoodsPrice表中没有，那就没有库存了，这个逻辑也很合理。（这种没有库存其实是没有这种规格了商品了，可以检测出来，提示用户商品失效）规格直接更改可以改变商品，SKU这样有点侵入式的感觉，感觉最好是规格信息变动不会影响线上业务，需要更新商品才会变动其他信息才比较好。实际上电商这种规格表的设计，每次更新商品，哪怕没有信息变化，就点击保存，都会引起SpecGoodsPrice（相当于产品表SKU表）变化，因为删除了旧数据，重新添加一遍，这样就导致了每次id都会变化，所以这也就是天猫商品销量只能统计某个商品，而不能统计某个SKU了，一个商品的生命周期可能有很多SKU生命周期，这也是一款产品下面有的人买的是上面没有的规格的原因。参考：[为什么在京东的商品详情页每点击一次商品参数就要刷新一次页面？](https://www.zhihu.com/question/27859589) 既然这个SKU id是变化了，那就不能用在业务逻辑中，可以忽略它，商品购买后订单记录指向的是商品的ID，SPU id，然后有一个规格组套餐: 套餐一…… 这样的字段，这个只是起展示作用的，没有其他意义了。购物车中其实也是这样的规格信息，起展示作用。但是tpshop的设计有一点新颖。那就是规格用了两张表：tb_spec和tb_spec_item 这样就就能得到一个key(spec_key)：其实就是spec_item_id 那么真的key_key…… 就能代表一组规格了，就是spec_id:spec_name 套餐: 套餐一 >[danger] 注意：tpshop将key的排序转变为小到大的排序，这很重要，前台也遵循这个排序，只有这样才能标识唯一的SKU。另外还要注意，key_name没有根据item_key的顺序，不然可能造成SPU下的不同SKU规格顺序不相同。这涉及到规格项排序问题（规格项顺序就是规格的顺序，如：颜色，尺码，套餐）而specInput的排序只是让规格值小的放在前面，便于合并单元格好看，应该不影响任何业务逻辑。另外规格值也要有顺序，便于展示时自由调整。所以设计到业务相关的顺序应该有规格（名）排序和规格值排序。其他的都没有排序，SKU也没有（只是逻辑数据而已）。 tpshop的设计是：首先为同类商品建立商品规格。可以建立多个规格，每个规格可以有多个规格项。然后这组规格就可以被该类型的商品选用了。注意这里是选用，而不是全部非得都要用。当选择了多个规格的多个规格项之后，就要得出选中的规格的规格项的笛卡尔乘积，乘积的值就是该商品SKU数量，也叫做规格组数量，一组规格的商品是不可再分的完整的商品。 ### 名词解释：颜色：`红色` `黄色` 尺码： `M码` `L码` `XL码` 套餐： `套餐一` ---- 上面说明了，这件商品规格的信息：该商品有**3种类型的规格**，**规格名称**分别为：`颜色`，`尺码`，`套餐` 其中颜色规格的规格值有：`红色`，`黄色` SKU就是笛卡尔乘积 T = R * S 这些规格共有六种交集。也就是说有六个SKU。SKU的数量登录规格的笛卡尔积，并且每个SKU都是完整的规格组，规格组由最小单元规格的键值对所组成，规格名 : 规格值。键值对组成了一个规格项。笛卡尔的每个交集都是唯一的，所以一个SPU下的SKU（规格组）也是唯一的。一个规格组的键值对的数量就是刚才选中的规格种类的数量，一个SPU下的每个SKU的规格规格项数量是一样的，规格的顺序也都是一样的，只是规格值不同。也就是说“键”都是一样的，只是“值”不同而已。如果不是这样，那就不合法。每一个规格组都包含某个规格的某个规格项。 `颜色:红色,尺码:M码,套餐:套餐一` **（规格组 SKU）** `颜色:红色` —— **规格项（键值对）** * * * * * ### 商品规格展示（两处）规格展示有两处，一处是后台，这个要注意，不要忘记了，这儿是选择，并不是类型下的规格都是的，也可以不选的。所以这个规格展示必须从规格表中读出来。第二处就是商品详情页的规格展示，这个是商品的全部SKU规格，也就是后台所有选中的规格，这个规格要从SKU表中读出来，thshop就是这么做的（纠错，tpshop其实还是从规格表中读出的，只不过用SKU中的数据从规格表中读而已，所以它要特别小心它的规格排序了，它也分别在前端后端做统一转换的了），但是iwebshop就多此一举，在商品表里面有个字段spec_array，他把所有规格sku放在这里存一份了，商品详情页面展示规格就是使用的这个字段的数据。这种方式太冗余了(其实这样也没什么不可，适当的时候反三范式也是好方法，免得每次计算这个数据麻烦)，从SKU表中很容易得到所需要的数据。拿到商品所有的SKU，然后处理下数据就可以了。这里要注意一个问题，那就是规格（名）排序的问题，有的算法需要考虑“顺序”一致的问题，请注意。 ### 扩展 tpshop的笛卡尔乘积实在服务端php计算的，采用的设计思想是通过将多个数组不断的转换为两个数组来进行计算，因为只有两个数组时才可以很简单的计算出笛卡尔乘积。 ~~~ /** * 多个数组的笛卡尔积 * * @param unknown_type $data */ function combineDika() { $data = func_get_args(); $data = current($data); $cnt = count($data); $result = array(); $arr1 = array_shift($data); foreach ($arr1 as $key => $item) { $result[] = array($item); } foreach ($data as $key => $item) { $result = combineArray($result, $item); } return $result; } /** * 两个数组的笛卡尔积 * @param unknown_type $arr1 * @param unknown_type $arr2 */ function combineArray($arr1, $arr2) { $result = array(); foreach ($arr1 as $item1) { foreach ($arr2 as $item2) { $temp = $item1; $temp[] = $item2; $result[] = $temp; } } return $result; } ~~~ 不过感觉这两个函数没有设计好，功能有融合，因为第二个函数的第一个参数只能是二维数组才可以。显然这一步又在第一个函数里面做了。 ### 参考： - [笛卡尔乘积](http://baike.baidu.com/link?url=ZC7bEfQVmex1SrG5U8LMZU1MAcxfSTItoKk17H3nVv0WcbvzKgiqDNHUHxOUnc_DWsBZV5cLUOhRHbA573ikZCLuwq4PAieVKYoNXx-83YafC7K3VtST34goTIuOOL03nHkaB1s1_n1HONPQU8QWtq2xiTylvbxaxEPmVyPTCzQbtvrYh2Lk74ld62BRh_ExhAzDHnen4JDnHn6B8bfMF4EIWWbM26z8XEPuGw2XbBW) - [js实现的笛卡尔乘积-商品发布](http://www.cnblogs.com/xumanbu/p/4552290.html) - [js 笛卡尔积算法与多重数组笛卡尔积的例子](http://blog.csdn.net/a473554142/article/details/48970225) - [淘宝、京东多规格组合商品的数据库设计](https://segmentfault.com/q/1010000005955316) - [非小型电子商务系统设计经验分享](http://www.cnblogs.com/mmmjiang13/archive/2012/07/05/2575538.html) - [再从淘宝数据结构来看电子商务中商品属性设计](http://www.cnblogs.com/mmmjiang13/archive/2011/08/03/2125640.html) ### 其他商品类型对应的规格和属性，这样的方式跟淘宝一样，其实不一定要这样，这很适用于相对标准化的商品，不太灵活，比如商品不能单独随意的添加规格和属性，比如外卖餐品的大份，小份，这只需要一个简单的规格就可以了，而且不是每个品类都有这样的规格，这样能够随意自定义就灵活多了。还有需要考虑如果修改类型的规格，规格值会对给类型的商品带来什么影响呢？这些都需要考虑的。还有商品变动，会对用户的购物车产生什么影响，等等要素。