引用：
VIEW を使うかというよりも、その VIEW を副問い合わせとみなして展開した SQL文(まさに MySQL 用のロジックが中間生成するSQL文がまさにそれです)が、適切な SQL かという観点が重要かと思います。

で、今回の vw_products_allclass は dtb_product_categories を結合していますが、その処理は必要ない気がします。(未検証)

必要ないテーブルを結合して、展開されたレコードを GROUP BY するというのは、全く無意味な処理だと思います。

そう考えると、結果的に本件の場合は「一般的なやり方」ではない気がしますね。

後発の ONE/DEPO なんかは、その辺りは相当気を使っているようです。「10万点の環境下で平均表示速度1秒〜3秒程」というのは、無駄の無い処理を心がけた賜物だと思います。(EC-CUBE みたいに高度な規格(ONE/DEPO では構成情報と呼びます)が無いという差もありますが)

引用：
規格の使用時に、価格の範囲表示(MIN〜MAX)があるので、少々厳しいかも。

あの生成ロジックが、分散してしまうのも嫌だなぁ・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。