商城商品3層選項演算法再優化

速度提高几百倍，記一次資料結構在實際工作中的運用
上文描述了商品3層選項 尺碼-顏色-性別，實現的效能優化過程。
原文實現了選擇第一層以後，第二層選項開放，選擇第二層以後，第三層選項開放。

我在知乎看到其轉載，發現有可以繼續改進的方案。
以下方案能實現，任意選擇某個選項以後，遮蔽其他層無法選擇的專案。

商品各選項分別編碼，然後hashcode = a * B * C + b * C + c。

可以建立一個表F，其元素值為二進位制位的集合，可以用數值或字串(因為這是js所以資料結構上不大方便)實現

對於所有(a,b,c)元素，其位標誌位
f = (1<<(a+B+C)) | (1<< (b+C)) | (1<<c);
F[hash(a,0,0)] |= f; F[hash(0,b,0)] |= f; F[hash(0,0,c)] |= f;
F[hash(a,b,0)] |= f; F[hash(0,b,c)] |= f; F[hash(a,0,c)] |= f;
另外使F[hash(0,0,0)] |= 全集;

如此，當前任意(a,b,c) (任意項可以未選，只要非全選)，查詢F[hash(a,b,c)]可得知其可選集合，把相應選項亮起即可。
此方案可選項總數<=31的都很好實現，>=31用陣列或字串代替標量數值。總共ABC個選項如果只有1000多，那簡直就是秒殺。

假如資料由後端下發或儲存於本地快取，那麼，任意兩選擇F的元素共有ab + bc + ac, 按9,10,11可選項即服務端傳送1011 + 1112 + 1012=232【稀疏】陣列即可。232的陣列，可以對應990種商品過濾，不過因為每個商品還是需要單獨發價格等其他資料。

---

如果不希望載入網頁後立刻要求後端傳輸所有可能商品，則可以在第一次選擇後由後端查詢其F(hash(0,b,0)]後將可選位及商品價格傳輸給前端。

---

作為後端，可能因商品庫存原因要動態刪除某個具體商品，上述資料結構並不合適反向刪除，但可以改為，F[hash(0,b,0)] = { 選項0被選次數 | 選項1被選次數 | …… }
某具體商品庫存不足時，減少其若干個hash的對應選項的次數，將位擴充到數量，即可實現增刪。
此方案可儲存於資料庫(欄位型別用pg的原生陣列)或json。