[EC-CUBE]
2.11.1 チェンジセットを随時適用中

[現象]
顧客管理-顧客マスタの検索と、メルマガ管理-配信内容設定の検索で、
購入金額、購入回数、最終購入日での検索が効かない。

調べたのですが、検索条件の問題ではなく、DBの該当項目が更新されていない気がします。

dtb_costomerのfirst_buy_date,last_buy_date,buy_times,buy_totalが入りません。
これらの項目に値が入るタイミングがいつなのかが不明ですが、、

確認をお願い致します。

kwhr1972さん、こんにちは。

チケットとして既に登録されていますよ。

#1248 顧客マスタの検索条件設定で、購入金額、購入回数が効いていない
http://svn.ec-cube.net/open_trac/ticket/1248

2.4系の頃には、購入の都度dtb_customerのbuy_times,buy_total等が更新される実装になっていましたが、2.11からこの更新処理がなくなっており、顧客マスタの検索側では、この項目が更新される事を前提に実装されたままなので、検索が効かなくなっているという具合です。

2.11での実装の方向としては、

引用：

とのことなので、2.4系の頃の仕様から変更になるようです。

----------------

リゾート会員権(エクシブ等)の売買・仲介

shuttaさん、おはようございます。

スミマセン。
チケットの確認漏れていました。。
次から気をつけます。m(__)m

じゃ、サブクエリ対応の方向みたいですね。


ここに書くものどうかと思いますが、、

既にある、購入商品とかのサブクエリですが、よく見たらINが多用されてますね。。
出来ればEXISTSの方がSQL負荷が軽くなるかと思います。

対応されるコミッターの方、合わせて検討をお願い致します。m(__)m

横から入ってくるようで申し訳ありません。

当該現象に関しまして、「登録・更新日」についても同様に検索が効かない（全データが検索結果として出てくる）ということはなかったでしょうか。

当方、プログラム知識がないもので検討のつけようがなく、この現象で困っております。

「登録・更新日」に係る現象の有無についてだけでも、教えていただければ幸いです。

> 既にある、購入商品とかのサブクエリですが、よく見たらINが多用されてますね。。
> 出来ればEXISTSの方がSQL負荷が軽くなるかと思います。

トレードオフとして可視性が悪くなったり、DB によってはパフォーマンスに変化がなかったりする事もあります。

なので、一辺倒ではなく、「どの場所を変えるとどう改善されるか」といった情報が寄せられると良いかと思います。

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

> 「登録・更新日」に係る現象の有無についてだけでも、教えていただければ幸いです。

プログラムを確認しましたが、dtb_customer.update_dateを抽出項目としている様です。

会員情報が更新されるタイミングでdtb_customer.update_dateが更新される作りのようなので、割と随時更新される項目だと思います。

意図する日付で抽出を行いたいなら、意図するタイミングだけ更新されるカラムを追加するなど、カスタマイズが必要かと思います。

引用：

確かに効果は環境に依存しますので、ひとまず自前カスタマイズに留めます。

試しに「購入商品コード」を書き換えてみました。
ソースは/data/class/SC_CustomerList.php

変更前：
$this->setWhere( "customer_id IN (SELECT customer_id FROM dtb_order WHERE order_id IN (SELECT order_id FROM dtb_order_detail WHERE product_code LIKE ? ))");

変更後：
$this->setWhere( "EXISTS (SELECT dtb_order.customer_id FROM dtb_order, dtb_order_detail WHERE dtb_order.customer_id = dtb_customer.customer_id AND dtb_order_detail.order_id = dtb_order.order_id AND dtb_order_detail.product_code LIKE ? )");

※インデックス追加作成：dtb_order_detail.order_id

なお、当方の環境はMySQL 5.*であり、他環境での動作確認は行っておりません。

なお、開発環境のデータ量が少なすぎる為、レスポンスが改善されたのかは不明です(笑)
試してみる方がいらっしゃいましたら報告して頂けると幸いです。
遅くなっている様なら、元に戻さなきゃ・・・

> プログラムを確認しましたが、dtb_customer.update_dateを抽出項目としている様です。

実動作を見ると、スルーしている感じですね・・・

Rondbell 様のおっしゃるとおり、「全データが検索結果として出てくる」状態が再現しました。

チケットを登録します。

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

チケットを登録しました。
http://svn.ec-cube.net/open_trac/ticket/1356

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

改修を行いました。
http://svn.ec-cube.net/open_trac/changeset/20977

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