株式会社ロックオン 梶原様

> もし、可能な方がいらっしゃれば、やはりMySQLでの性能が知りたいです。

下記記事の方法(1万商品)で、ベンチとってみました。
http://gihyo.jp/design/serial/01/ec_cube2011/0003

[2.12.0-dev r21428 + r21418 のパッチを適用]
商品一覧（あるカテゴリーの1ページ目を15件表示）: 1.78秒

(サーバは前述のノートPCですが、クライアントはリモートに変更しました。)


> あと、パッチを確認してみました。
> パッチをざっと見た限りではProduct系の処理以外ではあまり影響がないように見えます
> （決済モジュールもあまり影響しないですね、おそらく）が、あれで全てですか？

はい。上記ベンチは、そのパッチのみです。

dtb_products_class のキー情報の張替えでは無かったので、結果として改修規模は小さく済みましたね。(個人的には、その構造にも疑問を持っている部分ではありますが・・・。でも今回は楽させてもらいました。)

2012-1-30 15:54 の記事の内容は、さらに手を加えたものとなっていますが、これは木構造以外の部分のチューニングであり、別途のコミットを考えています。

ちなみに、同様のベンチで MySQL 1.6秒を切りそうです。


> 他、影響が出て修正すべき部分がないかご確認いただければありがたいです。

たしか、ベンチマークには影響が無いので実装を省略していたメソッドが1つありますが、小手先で対応できる類だったと思います。


> ですが、今回2.12にてプラグイン機能を搭載しますと、以降は少なくともEC-CUBE2系の中では、DB構造
> 変更は今以上にむずかしくなると思いますので、今回、大きな変更になりますが、入れるべきかどうか
> しっかり検討したいと思います。

プラグインが今後の EC-CUBE 本体の開発の妨げになりそうというのは、残念ですね・・・

私の実装は、小手先でできる範囲で粘ったものですが、他のコミッターさんはではもっと根本的な部分からといった案もあったようなので。

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

株式会社ロックオン 梶原様

状況に変化がありましたので、改めましてご報告させていただきます。


> パッチをざっと見た限りではProduct系の処理以外ではあまり影響がないように見えます
> （決済モジュールもあまり影響しないですね、おそらく）が、あれで全てですか？

先日未対応だったメソッドを含め、パッチを更新しました。
http://svn.ec-cube.net/open_trac/changeset/21434

2012-1-30 15:54 の記事の内容は、木構造に影響の影響を受けず動作するものですので、別チケットで処理しました。よって、前述のパッチが全てとなります。
http://svn.ec-cube.net/open_trac/ticket/1626

あとは正常な動作には影響をあたえるものではないと考えている部分で、いくつか木構造の名残による無駄なコードが残っています。この辺りは、将来に混乱や作業を残すことがないように、対応したいと思っています。

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

株式会社ロックオン 梶原様

> あとは正常な動作には影響をあたえるものではないと考えている部分で、いくつか木構造の名残による無駄なコードが残っています。この辺りは、将来に混乱や作業を残すことがないように、対応したいと思っています。

SC_Product.php にいくつか該当するものがありましたので、削除いたしました。

r21496 へのパッチとして、再アップしました。
http://svn.ec-cube.net/open_trac/changeset/21499


あとは、insert_data.sql が若干強引ですが、これは現状で改訂して他のコミットの影響を受けると、パッチの保守が大変になるためです。

この部分は、本体ソースへコミットするタイミングで改修させてください。

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

Seasoftさん

お疲れ様です。
株式会社ロックオンの梶原です。

お待たせして申し訳ございませんでした。

本件、Seasoftさんの案をversion-2_12-devへコミットしていただけますでしょうか。
＞Seasoftさん

まず、そちらを「α版：2/28リリース予定」にて採用させていただきたいと思います。
そして、他のコミッター様のご意見もいただきながら、DB構造の最終ジャッジはβ版までにしていきたいと思います。

今のところは、
　・木構造ではカスタマイズがしにくい
という意見を多く伺っており、その他、一から考え直し、規格自体使わないとか色々あるようですが、詰まる所みなさん
木構造をあまり望んでいないという意見が多数を占めていると感じました。
木構造の状態で、2.12で実装されるプラグインが作り辛い（＝プラグインが増えない）となると今後、更に誰も幸せ
にはならないと思いますので、DB仕様が右往左往する形にはなりますが、Seasoftさんの案を前向きな施策として
まずは選択させていただきました。
（もちろん、クリティカルな問題が出たり、今後の展開如何によって結局木構造になる可能性もありますが。）

今後、本件も踏まえて、プラグインを作成するという観点も入れつつ、沢山ご意見いただきたいと考えています。

以上、よろしくお願いいたします。

梶原さん,

引用：

この DB 構造のままリリースとなった場合, 商品データの互換性が無くなると思います.
(2.11 から 2.12 へはDB移行を伴なったアップグレードになると思います)

2.11 のユーザーがプラグインを使いたい場合は, 結構なコストがかかると予想されますが, そのあたりはどのようにお考えでしょうか?
また, 2.4 までのユーザーはどうなるのでしょうか?

個人的には, プラグインの普及のためには, 2.11 のユーザーがアップグレードしやすい環境を作ることが重要と考えています.
2.4 から苦労してアップグレードされた方も多数いらっしゃいますので, 2.11 のユーザーに強いいる負担は無視できないと思います.

木構造をやめたからといって, EC-CUBE の爆発的な普及の要因になるとは考えにくいです.
また, 繰り返しになりますが, 木構造だからといって, 極端にパフォーマンスが悪いわけではなく, 規格を使用しているユーザーもごく少数ではないかというお話もあります.

将来的には, 規格の仕様を見直していくべきだと思いますが, このタイミングでの仕様変更には反対です.

株式会社ロックオン 梶原様

> 本件、Seasoftさんの案をversion-2_12-devへコミットしていただけますでしょうか。

取り急ぎ、チケットの発行とコミットを行いました。
http://svn.ec-cube.net/open_trac/ticket/1641
http://svn.ec-cube.net/open_trac/changeset/21502

# しかし、insert_data.sql の変更は大変だ・・・


不具合があるようでしたら、α版公開までの間でも積極的に修正したいと思いますので、ご報告をいただけましたら幸いです。＞ 開発環境へアクセス可能な皆様

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

nanasess 様

テーブルの構造変更に関しましては、下記ページの SQL のような方法で行えると思います。
http://seasoft.jp1.cx/ec/%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88/2.12/2.11_2.12

開発作業の初期段階で実際に使用していたSQL文なので、最終的な実装との整合は未確認ですが、規格に関してコアな部分は、この程度だと考えています。

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

nanasessさん

お疲れ様です。
株式会社ロックオンの梶原です。

ご意見ありがとうございます！

引用：

仰る通り、2.11とのデータの互換性はなくなります。
今回悩んだのは、その互換性を無くしてまで変更するかどうかというまさにその部分です。
2.11から2.12へ移るにあたって、正直なところ、大きな変更を加えたくないと思っていたのも事実です。

ただ、2.11で展開し、本コミュニティサイトでの話の中で、規格の木構造はカスタマイズの障壁に
少なからずなっていることが分かりました。
おそらく、今のままの状態だとプラグインの作成にも支障がでると判断しました。
ここが変更の一番の理由です。

今後、2.12以降、EC-CUBEがプラグインという新しい機能の搭載と、新しいステージに行くにあたり、
プラグインを多く作成し、普及させることを第一優先として考えています。
また、プラグインが普及すると、よりDB変更がし辛くなると思いますので、DB変更を仮に行うとすれば、
プラグイン普及前のこのタイミングがベストであるということも理由の一つです。

さらに、
・速度は2.11から遜色なし
・現状の決済等のモジュールへの影響は最小限
・木構造の利点として考えていた、規格の追加というカスタマイズはそれほど需要がない
　（追加するにしても、規格ではなく異なるオプション設定の追加がスマートという意見もありました）
上記、コミュニティで話を展開してきた中であった通り、検討材料とさせていただきました。

もちろん、データの保全に関しては、引き続きデータ移行ツールにより検討していきたく思っています。

以上ですが、まずはα版にてしっかり確認していきたいと思います。
全会一致というわけにはいかないかもしれませんが、上記、ご理解いただければと思います。

引用：

このあたり, みなさんのご意見をお聞きしてみたいですね.
Seasoft 様の SQL 文でDBの変更ができるのは, 大変良いことだと思います.
しかし, 多くのユーザーが簡単に移行できるレベルではないと思います.

2.11 から, 2.12 へ, プログラミングがわからないデザイナーさんレベルのスキルで移行可能なら話は別ですが, 現状そういった考慮がされてないようなので.

# 2.11 が, かつて 2.5 として開発されていたように, バージョン表記なんかも考える必要があるかもしれません

追記.
個人的には, データ移行ツールの開発なんかよりも, もっと他の不具合修正とか, 置きざりになっている改善にパワーを注ぎたいです.
地味なところは, どうしても後回しになってしまっているんですよね...
そのせいで, 困っているユーザーはたくさんいます.
経済損失で考えると, 相当な額に及ぶと思います.

そういう機能はプラグインで!という話かもしれませんが, 後からインストールしなくてはいけない手間やリスクを考えると, 標準で対応しておきたい機能は(というか, 対応していないのがおかしい), まだたくさんあります.
そういった機能開発をずっとしたいと思いながらも, なかなか時間がとれないのは大変心苦しいですが...

引用：
今現在、2.11系がどの程度使われているのかってのが気になります。
まだ新規案件で2.11を利用する勇気が無いので。

----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。