MYSQLで検証しているのですが、
参照性合成、トリガ（MYSQLで設定できたかおぼろげ）の
設定がきちんとできていないため、
管理ページからデータの登録に失敗した場合に
（コードのバグ、タイムアウトなど）
カテゴリ、商品関連のテーブルのデータに整合性が
無くなりぐちゃぐちゃになる危険性があります。

たとえば、カテゴリ、商品のクロスリファレンスや
データ数をカウントしているテーブル等

1500件の商品データをCSVで試しに登録してみたところ
粉みじんになりました。

ちなみに、カテゴリを200件登録した後には商品登録が
タイムアウトになって画像が破棄されるものの、テキス
トデータのみ登録され、画像を修正しようにも更新がで
きません。
商品は1件だけです。
タイムアウトの後に、管理ページのセッションが無くなり、
どうしようもない状態になりました。

カテゴリを管理しているテーブルの自己参照方式と、キーの
持ち方、更新のロジックにパフォーマンスに影響する構造
が見受けられます。

ご検討ください。

EC-CUBE の開発は, 基本的に PostgreSQL で開発しているため, MySQL の対応は「とりあえず動く」というレベルです...

1. PostgreSQL で開発する
2. MySQL で動作するように(無理矢理)合わせる

という流れで開発しています.

外部キー制約や参照整合性設定など, DB 側でガチガチにするのが理想ですが, それをしようとすると, 全体的にほぼ作り直さなくてはならないと思いますorz

開発チームも, MySQL に関するノウハウが非常に乏しいため, 具体的な改善案をご教示頂き, 一緒に開発していけたら大変嬉しいです.

現在、ある通販業者さんからの依頼で、商品マスタ周りを色々と検証しています。その作業中に気づいたのですが、商品のCSV登録って、トランザクション張らずに動いているんですよね。

そして、DB に INSERT しながらバリデーションしているようで・・・

つまりは、登録中にエラーでコケれば、エラー発生以前の商品は登録されてしまうんですよね。

で、CSV ファイルのエラー箇所修正して、再実行などすると、重複状態に・・・

もしかすると、
> 1500件の商品データをCSVで試しに登録してみたところ
> 粉みじんになりました。
といった辺りにも関与しているのかなと思いました。

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

お世話様です。

PHPからのトランザクションの動作を少し検証してみました。

トランザクション自体が、CSVでアップロードされたデータを
処理するループの外にかかっているため、

LC_Page_Admin_Products_UploadCSV_Ex.phpの

// 実行時間を制限しない
set_time_limit(0);

の設定によるのか、トランザクションブロックの内側で
タイムアウトや強制終了する様な状況になると
データがコミットされてしますのではないでしょうか？

CSVでの登録は、

「IDを指定しない新規登録」
「IDを指定した更新」

のいずれかで処理している様に思われますので、

トランザクションの中で落ちた場合に、
データが中途半端に登録されるので、
落ちるタイミングによっては変なデータが残ってしまうの
かと思われます。
パフォーマンスは落ちますが、
現状では、CSVデータの1件毎に
トランザクションをかける方が良いのではないでしょうか？

また、

LC_Page_Admin_Products_UploadCSV_Ex.phpの

// 行カウント
if($line <= 1) {
continue;
}

は、$line < 1 としないと、
CSVで1件のデータは登録できないように思われますが．．．

思いつく登録時の流れ（対応）としては、

１、商品1件のスキーマ毎にトランザクションをかける
２、登録できたデータと登録できなかったデータを振り分けて
　　ログを吐き出す。
３、タイムアウトが起きない様に一定件数でクライアント
　　（ブラウザ）を介す様にする。
４、IDの指定が無い場合は、ID自動発行で新規登録する。
　　IDの指定がある場合は、該当データのある場合は更新
　　IDの指定がある場合で、該当データの無い場合は新規登録

このくらいのパターンがあれば、登録時の問題はいくらか
解消されるのではないかと思います。

後は、データベースの最適化でしょうか？
これまでの経験ですと、スクリプトなどのコーディングで
データベースエンジンをラッピングしようとすると大変な
ので、ストアドを介す様にして、ストアドの名前をなるべ
くそろえて、可能な限りデータベース側でラッピングした
方がスムーズの様です。
データベースの方言や拡張関数等もある程度ストアドで
吸収することも可能です。

時間が取れれば、開発に参加してみたいとも思います。

ご検討ください。

ちょっとバタバタしているので, ちょっとだけ反応します...

引用：

EC-CUBE はレンタルサーバーで使われることが多いので, ストアドは難しいのではないでしょうか.

専用サーバー向けの個別カスタマイズでしたら, ある程度の処理はストアドにしてしまっても良いかと思います.

引用：

是非とも一緒に開発しましょう!

# と言いつつ, 最近はあまり関われなくてスミマセン...

> EC-CUBE はレンタルサーバーで使われることが多いので, ストアドは難しいのではないでしょうか.

MySQL の管理GUIで見る限り、スキーマ下にストアドがついているので使えそうな感じもしますが、通常はブロックされるんですかね?

でも、MySQL 5 に有っても、MySQL 4 には有ったかなぁ…
# そろそろ、MySQL 4 とか捨てたほうが賢明なような ^^;

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

ちなみに...

レンタルサーバーのphpMyAdminでストアドを登録できるか
２社でチェックしてみましたが、
delimiterの変更ができない様で、
SQLがエラーになるようです。
phpMyAdminにてSQL発行時にdelimiterを指定できるような
記事も見受けましたが、設定なのかcsvでのインポートや
エクスポート時しか使えないようでした（？？？）

こちらは、ざっとしかチェックしてませんが、
スクリプトからストアド発行のコードを流しても
エラーになる感じです。

スクリプトからSQLを発行するより、コネクションのオーバーヘッドも下がるので、データベースでやった方が良いと思うのですが、
慣例的にMySQLへ直接接続できるような環境でないと難しいんでしょうか？
セキュリティもいくらか上がるんじゃないかと．．．

phpMyAdminでSQL発行時にdelimiterの指定をする方法を知っている方がいたら教えていただきたいです。
設定なのでしょうか？

バージョンはphpMyAdmin 2.7.0-pl2でした。
個人的にもPostgreSQLの方が好きではありますが．．．

引用：
「ループの外にかかっている」のは、多分正しいんですよ。むしろ、内側でやっていたら、マズいはずです。(ソース未確認)

で、偶然関係ありそうな、書き込みがありました。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=3504&forum=1

MySQL の仕様により、ALTER でコミットが働いていたようですね・・・
う〜ん。トランザクションを後付けした DB だけに、MySQL はそのへん弱いですね。

とりあえず、直してみました。
http://svn.ec-cube.net/open_trac/changeset/17852

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