受注テーブル構成の変更

[shinichi-takahashi]

dtb_shipment_itemと内容が重複しているため、dtb_order_detailを廃止し、
以下のようにリレーションを変更したいと思っています。

dtb_order 1-n dtb_shipping n-n dtb_shipment_item

これによって、
複数配送先を考慮した形でテーブルで再設計することで、ソースがシンプルになります。
集計の際もdtb_orderを起点に容易に行うことができるため、デメリットはほぼないと言ってもいいと思います。
まずはみなさんのご意見を伺いたいです。

[ttsuru]

@shinichi-takahashi
dtb_order 1-n dtb_shipping n-n dtb_shipment_item
の方がモデリング的には良さそうな気がしますがいかがでしょうか。

[shinichi-takahashi]

@ttsuru
同商品を別配送先でそれぞれ購入した場合はn-nですね。
失礼しました。

[ttsuru]

@shinichi-takahashi
修正ありがとうございます。いいと思います！
いまのモデルはデータの修正や処理が複雑になっていると思います。
配送がないダウンロードなどの場合はshippingにorderと同じ情報を入れればいいんですかね。

[shinichi-takahashi]

@ttsuru
配送がない場合は、（配送先なし） を入れるほうがいいのではないでしょうか。

[ttsuru]

@shinichi-takahashi
null ということでしょうか。

[shinichi-takahashi]

@ttsuru
nullではないです。
上記で意図しているのは、2.13系の 配送無し(ダウンロード商品用) のように、配送情報がないよ、っていう情報を入れてあげるほうがいいのではないかな、と思ってます。
というより、配送自体しない＝無意味なデータなので、nullでもいいかもしれません。

[ttsuru]

@shinichi-takahashi
nullを入れる + 配送なしフラグ でもいいかもしれませんね。
ちなみに、配送先ごとに shipping_num もデフォルトで欲しいですね。

[shinichi-takahashi]

@ttsuru
EC-CUBE3では、DL商品機能自体がデフォルトからなくなっているので、
配送先が入っていても、配送方法で送料０のものを指定しておくなどの処理になると思います。
なので、フラグ管理より、料金計算を制御するまで（今回の場合は送料０円として制御する）がEC-CUBEとして担う役割になるのではないでしょうか。

shipping_numはdtb_order_detailのquantityですかね？もちろん必要になってきます！

[ttsuru]

@shinichi-takahashi
そしたらnull許可でいいのではないでしょうか。

shipping_num は佐川などの伝票番号です。
デフォで入れる欄を決め打ちしていただきたいです。

[shinichi-takahashi]

@ttsuru
nullだとdtb_shippingがなくなっちゃいません？？
dtb_order 1-n dtb_shipping n-n dtb_shipment_item

dtb_shipping.shipping_numですね。
いつも拡張する機能の一つなので、入れてしまってもいいかもしれませんね！

[ttsuru]

@shinichi-takahashi
dtb_shipping ないの配送先情報をnullという意味でした。失礼いたしました。

[shinichi-takahashi]

@ttsuru
そちらでしたら大丈夫かと思います。

nullを入れる + 配送なしフラグ でもいいかもしれませんね。

dtb_deliveryに「この項目を選択した場合は、配送先がnullになるよ」的なフラグが必要になることを考慮したものだったんですね。

[nanasess]

もう、互換性は考慮しないということでよろしいですか？

[nobuhiko]

shipping_num は2系でも用意されてましたが、使用されていないカラムとして最終的に削除されました
カラムを作るのであれば、formも用意したほうがよいかと思います

[shinichi-takahashi]

@nanasess

もう、互換性は考慮しない

既に2系のDBをそもまま移行して3系でも使えるものではないと思っています。
移行時の変換が不可能な変更になるわけでもないと思います。

[shinichi-takahashi]

@nobuhiko
そうなんですね。経緯を知りませんでした。

カラムを作るのであれば、formも用意

そうですね。
もし操作できるカラムが増えた場合には、適宜テンプレートにも手を加える必要がでてきます。

[ttsuru]

各後払いの普及や、配送番号の管理や通知を行うニーズが大きくなっていると思います。
配送会社と配送番号程度はデフォで用意した方が良いかと思います・・・

[nobuhiko]

@shinichi-takahashi
これですね。 http://svn.ec-cube.net/open_trac/ticket/2556

@ttsuru
住所とかのバリデーションもヤマト・佐川の仕様に最低限合わせておいてもらえるとみんな幸せですよね。

[ttsuru]

@nobuhiko
ですねぇ・・・。
これデフォじゃないとオレオレスキーマでいろんなとこにデータが散ってしまいますね。

[shinichi-takahashi]

@nobuhiko
ありがとうございます！
ECにおいて配送がない、っていうパターンは（DL商品は例外として）ありえないと思うので、nullableでおいておくほうが幸せですよね。
住所のバリデーションについては、ユースケースと合わせてご教示いただけると助かります。

[nobuhiko]

ヤマトが一番厳しいと思いますが
お届け先住所 都道府県（４文字）＋市区郡町村（１２文字）32文字/64文字 （全角/半角）
お届け先住所（アパートマンション名）16文字/32文字 （全角/半角）
お届け先名 16文字/32文字 （全角/半角）
http://bmypage.kuronekoyamato.co.jp/bmypage/pdf//exchange.pdf

楽天を見てもそこまで厳しくしてないので厳密にする必要があるかはわかりませんが参考まで

[shinichi-takahashi]

@nobuhiko
ありがとうございます。
ミニマムに合わせないとハミ出たときに処理大変ですよね。。

[Yangsin]

#2408 へ統合