木構造が問題というより、現在の規格機能に関するＤＢ仕様全体に問題があると思っています。
2.4系の仕様も、それはそれでまた問題があると思います。

規格機能を実現するための仕様と実装を、ゼロから考え直す方が良いのでは常々思っており、規格機能周りの見直しは事ある毎に提案はしているのですが・・・

まず、木構造は不必要のはずです。
（そのために相当苦労している）

また木構造が高速化に寄与する部分が残念ながら現時点では見当たらないです。（2.11.0β時にはあったような気がしますが・・・）

一方、ゼロから見直さないのであれば、右や左に中途半端な内部仕様変更をするのは良くないとは思っています。
（良い実装案を示せれば良いのです・・・）

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

規格で微妙に実現できない案件の場合に、規格をカスタマイズするよりも
規格っぽい機能を追加することが多いので参考になるかはわかりませんが。

引用：

仕様を深く理解しているわけではありませんが、
「早くなるなら」＆「好み的に」木構造は放棄でいいと思います。
「放棄"が"いい」ではない程度。

引用：

6件中0件です。

EC-CUBE 2.11 は、EC-CUBE 2.4 と比較して、速度の低下が顕著なケースが見受けられます。
そこで、私どもでは先日開発が開始された EC-CUBE 2.12 の開発に当たりまして、商品一覧画面の速度改善を試みています。
その中で、データの内部構造に手を加えないと改善が難しい部分があり、皆様の意見を伺わせてください。


まず、前提としまして、#781で木構造に変更された規格が (チケットの説明文とは相違するのですが) 速度面でのネックとなっていると考えています。

木構造が悪いということではなく、実装が未成熟な段階とも考えられますが、既に5回目の正式リリースである EC-CUBE 2.11.4 でも改善が見られないことから、木構造を維持して改善していくのは(無理ではないにしても)難しいのではないかと思います。

そこで実際に、EC-CUBE 2.12 デベロッパー版 (r21394) を基にして、dtb_class_combination を使わずに dtb_products_class のみで処理するようにカスタマイズをしてみました。すると、商品一覧画面は PostgreSQL で約1.8倍、MySQL では約12.5倍の処理速度を観測しました。

PostgreSQL 9.0.1: 2.15秒 → 1.17秒
MySQL 5.5.16: 16.40秒 → 1.31秒

※ 全体を改修したのではなく、商品一覧画面の主要な処理のみを改修した段階での暫定値です。
※ EC-CUBE データ生成スクリプトを使用して、100商品を登録した状態です。


さて、前置きが長くなりました m(_ _)m　ここからが、本題の質問です。

・「高速化をして木構造を放棄する」のと「木構造を維持する」のと、どちらを望みますか?
　(木構造を放棄する場合、EC-CUBE 2.4 の商品規格情報の持ち方に近くなります。)

・規格の木構造を生かしたサイト構築の経験はありますか?
　(EC-CUBE 2.11 に関してです。複数のサイトを開発された方は、「○件中△件」といった回答をいただけると幸いです。)

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