EC-CUBE 開発コミュニティ

機能要望 > その他 > 規格まわりの内部構成変更について

その他

投稿者	スレッド
nanasess	投稿日時: 2010/9/22 10:36 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用： ECCUOREさんは書きました：現在、ダウンロード販売を規格に対応しております。ありがとうございます! 引用：その関係で、規格について質問です。 dtb_class_combination　は、規格が無い商品の時も必要でしょうか？現状、規格が無い商品が商品一覧画面で、全て品切れ表示になっています。規格が無い商品は必要ありません. dtb_products_class.class_combination_id は NULL になります. ただし, 規格のある商品でも dtb_products_class.class_combination_id が NULL のレコードは生成され, dtb_products_class.del_flg は 1 (論理削除)となります. 引用： SC_Product getProductsClassByProductIds で　dtb_class_combination　をLEFT JOIN していますので、データが無い場合、LEVELがNULLになり LEVEL判定（getProductsClassFullByProductId）で、商品情報がLOSTしているように見受けられますが、如何でしょうか？規格無しにも対応したつもりだったのですが, version-2_5-dev へマージした際にデグレが発生したかもしれません. ちょっと調べてみます. ありがとうございます.

ECCUORE	投稿日時: 2010/9/22 10:57 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更についてついでの質問で申し訳ありません。規格の変更で、カートやオーダーテーブルの仕組みに影響が出ると思いますので、少し質問させて頂きます。質問１： 2.5からは、商品を一意に特定するキーは、dtb_products_classの、product_class_idになるのでしょうか？それとも、product_idも一応使った方が良いのでしょうか？質問２： dtb_order_detailにあるclasscategory_id1とclasscategory_id2は、今まで通り、使用して、dtb_class_combination　の　parent_class_combination_id、classcategory_id　がそれぞれ入る形になるのでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/9/22 11:19 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更についてまだまだ不完全で申し訳ございません... 引用： ECCUOREさんは書きました：質問１： 2.5からは、商品を一意に特定するキーは、dtb_products_classの、product_class_idになるのでしょうか？それとも、product_idも一応使った方が良いのでしょうか？「商品」という括りでは, product_id ですが, 価格などの「商品規格」を一意に特定するのは product_class_id になります. 引用：質問２： dtb_order_detailにあるclasscategory_id1とclasscategory_id1は、今まで通り、使用して、dtb_class_combination　の　parent_class_combination_id、classcategory_id　がそれぞれ入る形になるのでしょうか？現状ではそのかたちですが, product_class_id を格納したほうが良さげですね... カートの中の商品なども, classcategory_id1, classcategory_id1 で特定していますが, product_class_id を使用した方が良いと思っています.

seasoft	投稿日時: 2010/9/22 11:39 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 規格まわりの内部構成変更について改訂後の規格については、まだ十分に把握できていませんが、product_class_id の扱いについては、前々から気になっていた部分でして、横から失礼いたします。私も、product_class_id がキーとして使われていない事は気になっていました。反面 product_class_id としてキーを用意せずに、複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でプライマリキーを組んでも良いのでは、とも思っていました。ユニークを保つ必要がある性質のものだとも思いますし。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

ECCUORE	投稿日時: 2010/9/22 11:52 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更について引用： seasoftさんは書きました：複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でプライマリキーこの件で、少し気になる事があります。現状、class_combination_idがNULLになるケースがあるという事なので、購入後に商品を特定するようなケースでは、product_class_id以外に、小細工せずに一意に特定することができなくなるのではないかと思います。実行SQL： SELECT pc.product_code AS product_code, pc.product_id AS product_id, pc.product_class_id AS product_class_id, pc.class_combination_id AS class_combination_id, cc2.classcategory_id AS classcategory_id1, cc1.classcategory_id AS classcategory_id2 FROM dtb_products_class pc LEFT JOIN dtb_class_combination cc1 ON pc.class_combination_id = cc1.class_combination_id LEFT JOIN dtb_class_combination cc2 ON cc1.parent_class_combination_id = cc2.class_combination_id 結果： +--------------+------------+------------------+----------------------+-------------------+-------------------+ \| product_code \| product_id \| product_class_id \| class_combination_id \| classcategory_id1 \| classcategory_id2 \| +--------------+------------+------------------+----------------------+-------------------+-------------------+ \| ice-01 \| 1 \| 1 \| 10 \| 3 \| 6 \| \| ice-01 \| 1 \| 2 \| 11 \| 3 \| 5 \| \| ice-01 \| 1 \| 3 \| 12 \| 3 \| 4 \| \| ice-01 \| 1 \| 4 \| 13 \| 2 \| 6 \| \| ice-01 \| 1 \| 5 \| 14 \| 2 \| 5 \| \| ice-01 \| 1 \| 6 \| 15 \| 2 \| 4 \| \| ice-01 \| 1 \| 7 \| 16 \| 1 \| 6 \| \| ice-01 \| 1 \| 8 \| 17 \| 1 \| 5 \| \| ice-01 \| 1 \| 9 \| 18 \| 1 \| 4 \| \| nabe-01 \| 2 \| 10 \| NULL \| NULL \| NULL \| +--------------+------------+------------------+----------------------+-------------------+-------------------+ とはいえ、全体的にproduct_class_idをキーにするのは、かなり大がかりな修正になりそうですしね。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/9/22 11:52 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用：反面 product_class_id としてキーを用意せずに、複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でキーを組んでも良いのでは、とも思っていました。ユニークを保つ必要がある性質のものだとも思いますし。最初は, 複数キーも考えたのですが, * class_combination_id が NULL になる場合があること * EC-CUBE1.x からの慣習で, あまり複数キーが使われてないことから, product_class_id を流用するようにしました. そもそも, 1.x の頃は主キーという概念が無かったので, product_class_id が使われてなかったのだと思われます. また, ソースのコメントに書いていますが, 現在は dtb_class_combination テーブルを DELETE/INSERT で処理していますが, 本来的には UPDATE の方が良い気がします.

seasoft	投稿日時: 2010/9/22 12:20 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 規格まわりの内部構成変更について ECCUORE 様、nanasess 様なるほど、従来の classcategory_id1, classcategory_id2 は NOT NULL DEFAULT 0 でしたが、 class_combination_id は、NULL DEFAULT NULL なわけですね。とりあえず、現状を把握できました。ありがとうございます。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2010/9/22 14:01 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用：引用： SC_Product getProductsClassByProductIds で　dtb_class_combination　をLEFT JOIN していますので、データが無い場合、LEVELがNULLになり LEVEL判定（getProductsClassFullByProductId）で、商品情報がLOSTしているように見受けられますが、如何でしょうか？規格無しにも対応したつもりだったのですが, version-2_5-dev へマージした際にデグレが発生したかもしれません. ちょっと調べてみます. ありがとうございます. r18820 で修正しました. http://svn.ec-cube.net/open_trac/changeset/18820

ECCUORE	投稿日時: 2010/9/27 10:31 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更について引用：カートの中の商品なども, classcategory_id1, classcategory_id1 で特定していますが, product_class_id を使用した方が良いと思っています. 今後、カートやオーダーテーブルでは、classcategory_id1,classcategory_id2　を使わないで、product_class_id を使うと考えてよろしいでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/9/27 10:44 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用： ECCUOREさんは書きました：今後、カートやオーダーテーブルでは、classcategory_id1,classcategory_id2　を使わないで、product_class_id を使うと考えてよろしいでしょうか？はい, その方向で考えています. # 修正が追いついてなくてすみません...

« 1 (2) 3 »