Q&A
ありがとうございます。
確かに…一列だけ更新頻度が多いので、在庫管理用のテーブルを用意したいと思います。
そこで、在庫管理用のテーブルのイメージの確認で追加の質問となり恐縮ですが、
１、在庫管理用のテーブルは、商品の数だけレコードができて、出入庫の度に数をUPDATEしていく、ということですよね？
2, 決済しようとして失敗した、
カートに入れたので在庫を抑えたけどやっぱりやめた、といった際は、在庫を減らしたけど、その分足し戻す、という流れになるのでしょうか…
質問ばかりですみません！
小規模なECサイトを構築予定です。
在庫がある商品を扱う予定ですが、その商品の在庫を管理するテーブルの設計について、
以下のように考えております。
が、在庫がある商品を扱ったことがないので、本当にこのような設計でよいか悩んでおります…
【テーブル：product】
商品を管理するテーブル
id：オートインクリメント
name：商品の名前
price：価格
image：商品の画像URL
description：商品の説明
yuko_flg：商品の有効/無効
stock：在庫
created_at：登録日
【テーブル：inout_store】
商品の出入りを管理するテーブル
id：オートインクリメント
product_id：テーブルproductのid
num：入庫、出入庫の数
memo：メモ
created_at：登録日
【テーブル：order】
id：オートインクリメント
order_num：購入した数
・・・購入情報等。（省略）
・productテーブルは商品を管理するテーブルで、管理者が管理画面から商品を登録したり
修正した際にINSERTやUPDATEされる。※stockカラム以外
・inout_storeテーブルは、商品の出入庫を登録するテーブル。
商品を納入したり、ダメになったりした際に+の数や-の数を管理者は管理画面から商品IDと共に登録する。登録すると、inout_storeテーブルにINSERTすると同時に、productテーブルのstockカラムの数をその数だけプラス/マイナス（UPDATE）する。
・ユーザーがECサイトから注文するとorderテーブルに購入した数等をINSERTする。と同時にproductテーブルのstockカラムの数をその数だけマイナス（UPDATE）する。
というように、productテーブルのstockカラムには、常に、いくつ在庫があるかが登録される。
・・・購入されたりした際に、いちいちproductテーブルのstockカラムをUPDATEする設計ですが、これはおかしいでしょうか？
最新の在庫の管理をどのようにやるべきか、アドバイスいただけますと幸いです。
回答2件
0
解決済みですが、
失敗から学ぶRDBの正しい歩き方
の「失われた事実」の項がとても役に立つと思うのでご紹介まで。
例えば取引履歴を残せるようにしないと業務要件的に大変ですよということが書いてあります。
パフォーマンスも重要ですが、それよりもどんな業務要件が存在するか、それをRDBMSで表現できるのかということをまずは整理して設計してみることをお勧めします。
投稿2020/09/03 13:42
編集2020/09/03 13:46
総合スコア18713
0
ベストアンサー
私なら商品マスターと商品点数（在庫）マスターとを分けますね。
もしも、価格設定も変更頻度が多いのであれば、商品マスターから分離して商品点数（在庫）マスターに移すことも考えるかな。
変更頻度が多いのと少ないのとを同一テーブルに格納するのは非効率な気がします。
まぁ、数十とか数百くらいのオーダーなら、大差ないのかもしれませんが。
投稿2020/09/03 12:03
退会済みユーザー
総合スコア0
在庫ひとつひとつにシリアルナンバーみたいなユニークな番号をつけるのでなければ、
在庫の状態ごとにカラムを設けて、カートに入ったら、決済処理中なら、決済完了したら、発送したら、
などと状態の管理に使ってもいいかもしれない。
（サイト内ポイント付与とかあるともっとややこしくなりそう。）
ありがとうございます！
そのような方向で設計したいと思います！
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2020/09/03 13:47
2020/09/03 13:50
2020/09/08 13:10