最近業務上碰到的一個難題, 分享出來給大家瞧瞧.
PS: 本文使用 php 示範, 實作思路不局限于語言
需求
在電商領域, 有 sku 和 spu 這 2 個概念:
- sku 就是表示一個商品, 使用者最後加到購物車中的那個
- spu 是一組商品, 比如一件衣服有
等不同型号, 那麼每個資料就是一個 sku, 這組 sku 的集合就是 spuL XL XXL
假如我們有一個sku 為 4483094 的商品, 擷取到的商品 spu 資訊資訊如下:
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLiADNyEzLcd3LcJzLcJzdllmVldWYtl2Q3UCcpJHdz9CX05WZpJ3bt8Gd1F2LcJjcn9WTldWYtl2Pn5GcukDM1gDZ0cTM3kTMkFDMlJTL5kzM3YTNvw1cldWYtl2XkF2bsBXdvw1bp5SdoNnbhlmauMXZnFWbp1CZh9GbwV3Lc9CX6MHc0RHaiojIsJye.png)
這裡提供了 json 版的資料, 友善感興趣的朋友自己嘗試
{"顔色":{"曜石黑":[4483094],"草木綠":[3893503],"鑽雕藍":[3893493],"鑽雕金":[4736669,4483110,4483074],"陶瓷白":[4483100]},"版本":{"128GB":[4483100, 4483074],"64GB":[3893493,4736669,3893503,4483094,4483110]},"普通版":{"普通版":[3893493,4483100,3893503,4483094,4483110,4483074],"移動4G+版":[4736669]}}
spu 資訊的資料層級很清晰:
- 第一層表示的規格
- 第二層表示的規格包含的屬性
- 第三層就是這個屬性下有哪些 sku
接着, 來看看我們的需求:
- 擷取 sku 有哪些屬性
- 使用者選擇了規格屬性時, 判斷其他規格的屬性是否可選
- 隐藏需求: 資料怎麼存以及 CRUD
需求1: sku 有哪些屬性呢
一次簡單的周遊即可
// $spuArr: spu資訊格式化後的數組 $specArr['顔色']['曜石黑']
// $spuSet = []; // spu下有多少 sku
$skuSpec = []; // sku的規格屬性資訊
foreach ($spuArr as $spec => $specArr) {
foreach ($specArr as $attr => $skuArr) {
// $spuSet = $spuSet + $skuArr; // 數組并集
foreach ($skuArr as $sku) {
$skuSpec[$sku][] = $attr;
}
}
}
// spu下有多少sku
// var_dump($spuSet);
// var_dump(array_keys($skuSpec));
// sku的屬性資訊
var_dump($skuSpec);
// 指定 sku 的屬性資訊
var_dump(join(' ', $skuSpec[4483094]));
最後擷取到 sku 為 4483094 的商品的屬性資訊:
曜石黑 64GB 普通版
PS: 我之前在求
spu 下有哪些 sku
犯了一個失誤, 通過周遊整個 $spuArr, 當做集合問題來求解(見上面注釋掉的代碼), 但是請仔細觀察資料 -- 每一層規格都包含了此 spu 下的所有 sku
資料有意思~ 多觀察, 多體會~
2. 使用者選擇了規格屬性時, 判斷其他規格的屬性是否可選
其實是很簡單的交集就可以解決
// 初始狀态, 使用者還沒有選擇規格屬性, 所有規格屬性都可選
// 使用者選擇了規格屬性時, 判斷其他規格的屬性是否可選
$attrSelect = ['顔色' => '曜石黑']; // 使用者選擇了的規格屬性
$attrSku = []; // 擁有這些屬性的 sku
foreach ($attrSelect as $spec => $attr) {
if (!$attrSku) {
$attrSku = $spuArr[$spec][$attr];
} else {
$attrSku = array_intersect($attrSku, $spuArr[$spec][$attr]); // 交集
}
}
// var_dump($attrSku);
// 判斷其他規格的屬性是否可選
foreach ($spuArr as $spec => $specArr) {
if (!isset($attrSelect[$spec])) { // 此規格下使用者沒有選擇屬性, 判斷次規格下的屬性是否可選
foreach ($specArr as $attr => $skuArr) {
$spuArr[$spec][$attr] = array_intersect($attrSku, $skuArr); // 交集, 如果為空, 則此屬性不可選
}
}
}
var_dump($spuArr);
3. 隐藏需求: 資料怎麼存呢? 要考慮到 CRUD
需求1 的存儲比較簡單, 可以給 sku表添加一個字段
attr
, 用來存商品的所有屬性
需求2 的存儲怎麼設計呢? 直覺的感受是, 我們會有這些表:
- spu表, 自增ID
- sku表: 自增ID + spu_id(1 : n) + attr(需求1 中格式化後的屬性資訊)
- spec表(規格表): 自增ID
- spec_attr表(規格屬性表): 自增ID + spec_id
- attr_sku表(屬性與sku關系對應表): 自增ID + sku_id + spec_attr_id, 其實是上面第二層資料和第三層資料的映射
5個ID, 你還 hold 住麼?
- 解決需求2的問題時, 我們需要從 5 張表裡取出資料并格式化成
$spuArr
- 新增 spu 資料的時候, 我們需要更新 5 張表
- 如果 spu 資料有變化, 比如某個屬性下的商品沒貨了, 嗯, 又是 5 張表
就問你怕不怕?
通過格式化的
$spuArr
資料, 我們已經可以解決我們的需求, 也就是說, 無論我們的資料怎麼存, 最後我們都會格式化出
$spuArr
資料來解決問題, 為什麼不可以直接這樣存儲呢:
- sku表: 自增ID + spu_id + attr(需求1 中格式化後的屬性資訊), spu_id 隻用來辨別一組 sku, 可以用 id 生成器生成
- spu_info表: spu_id +
json_encode($spuArr)
隻用 2 張表, 就完成了我們的需求
json_encode($spuArr)
這樣的文檔型資料, 可以考慮使用 mongoDB
寫在最後
- 商品搜尋系統 可以錄入 sku表的 attr, 實作搜尋商品屬性的功能
- 原來的系統沒有 spu 的概念, 隻有 goods 表(商品), 流程依靠 goods 表都走通了, 怎麼進行 sku 和 spu 的拆分呢? -- 其實 sku 表就相當于系統現有的 goods 表, 按照需求3 的方式錄入資料即可
- 大道至易: 不要過度設計 不要過度設計 不要過度設計
- 算法 - 并查集: 有多個不相交的集合, 怎麼快速找到一個數屬于哪個集合呢?