バージョン選択

フォーラム

メニュー

オンライン状況

45 人のユーザが現在オンラインです。 (28 人のユーザが フォーラム を参照しています。)
登録ユーザ: 0
ゲスト: 45
もっと...

サイト内検索

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

その他

新規スレッドを追加する

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
nanasess
投稿日時: 2010/9/22 10:36
対応状況: −−−
登録日: 2006/9/9
居住地:
投稿: 2275
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: 規格まわりの内部構成変更について
ついでの質問で申し訳ありません。
規格の変更で、カートやオーダーテーブルの仕組みに影響が出ると思いますので、少し質問させて頂きます。

質問1:
2.5からは、商品を一意に特定するキーは、dtb_products_classの、product_class_idになるのでしょうか?
それとも、product_idも一応使った方が良いのでしょうか?

質問2:
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
居住地:
投稿: 2275
Re: 規格まわりの内部構成変更について
まだまだ不完全で申し訳ございません...

引用:

ECCUOREさんは書きました:

質問1:
2.5からは、商品を一意に特定するキーは、dtb_products_classの、product_class_idになるのでしょうか?
それとも、product_idも一応使った方が良いのでしょうか?


「商品」という括りでは, product_id ですが, 価格などの「商品規格」を一意に特定するのは product_class_id になります.

引用:

質問2:
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
居住地:
投稿: 7333
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
居住地:
投稿: 2275
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
居住地:
投稿: 7333
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
居住地:
投稿: 2275
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
居住地:
投稿: 2275
Re: 規格まわりの内部構成変更について
引用:

ECCUOREさんは書きました:

今後、カートやオーダーテーブルでは、classcategory_id1,classcategory_id2 を使わないで、product_class_id を使うと考えてよろしいでしょうか?


はい, その方向で考えています.

# 修正が追いついてなくてすみません...
« 1 (2) 3 »
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ


 



ログイン



統計情報

総メンバー数は76,865名です
総投稿数は105,255件です

投稿数ランキング

1
seasoft
7333
2
468
3217
3
AMUAMU
2712
4
nanasess
2275
5
umebius
2085
6
yuh
1669
7
red
1556
8
h_tanaka
1195
9
tsuji
944
10
fukap
907
11
shutta
835
12
tao_s
794
13 ramrun 789
14 karin 689
15 sumida 641
16
homan
633
17 DELIGHT 572
18
patapata
502
19
flealog
485
20 tonton 437


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.