Q&A
オプションにもid持たせて、注文idと商品idとオプションidでユニークになるようにしたら良いのでは？
前提
ある商品の注文管理システムのDB設計を考えています。
注文をする際に管理者が事前に登録をしておいたオプション事項を注文者が設定できる場合の注文管理の方法が分からないので質問させていただきました。
例
お弁当を例に簡易的に、
- 商品は商品Aひとつのみ
- 注文の際に「サイズ」(大,中,小), 「箸」(あり,なし)が選択できる
- これらオプションの種類は管理者が別の管理画面にて追加、削除ができる。
(ex. 後から「袋」(あり,なし）が追加できる)
これらを実現するためにまず下記のようにテーブル設計。
■ 商品テーブル
| id | 名前 |
|---|---|
| 1 | 商品A |
■ オプションテーブル
| id | 商品id | 名前 |
|---|---|---|
| 1 | 1 | サイズ |
| 2 | 1 | 箸 |
■ オプション明細テーブル
| id | オプションid | 名前 |
|---|---|---|
| 1 | 1 | 大 |
| 2 | 1 | 中 |
| 3 | 1 | 小 |
| 4 | 2 | あり |
| 5 | 2 | なし |
そして、とある利用者が一度に注文を
・商品A / サイズ大 / 箸あり => 3個
・商品A / サイズ中 / 箸あり => 2個
・商品A / サイズ中 / 箸なし => 2個
とできるとします。
検討したこと
良い設計が思いつかず、一つ思いついたのは下記です。
■ 注文
| id | ユーザid | 日付 | 個数 |
|---|---|---|---|
| 1 | 1 | 20220607 | 7 |
■注文明細
| id | 注文id | オプション | 個数 |
|---|---|---|---|
| 1 | 1 | 1,4 | 3 |
| 2 | 1 | 2,4 | 2 |
| 3 | 1 | 2,5 | 2 |
(「オプション」へ設定されたオプション明細のidを列挙)
1カラムに複数値入れるのはアンチパターンと言われているので、最悪これなのかなと思いつつ他に良い方法が思いつきません。
オプションが固定であればカラムをオプションごとに作ればよいのですが。。。
回答4件
0
現状を素直に正規化するなら、
注文明細テーブルを二つに分ける形でしょうね
（注文テーブルの「個数」も無い方がいいとは思います）
注文明細
| id | 注文id | 個数 |
|---|---|---|
| 1 | 1 | 3 |
| 2 | 1 | 2 |
| 3 | 1 | 2 |
注文明細-オプション明細
| id | 注文明細id | オプション明細id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 4 |
| 3 | 2 | 2 |
| 4 | 2 | 4 |
| 5 | 3 | 2 |
| 6 | 3 | 5 |
ただ、
1カラムに複数値入れるのはアンチパターンと言われているので、
については、RDBMSの機能と使い方次第でどっちが適しているかが変わってくるので、
実際の条件に近づけて、クエリを作って比較してみるのが良いのかなと思います。
投稿2022/06/07 05:55
総合スコア18713
回答ありがとうございます。
なるほど！
正規化するならそうなるのですねー
全否定されるアンチパターンではないようなので、正規化する場合と比較して実装してみます。
0
ベストアンサー
どの程度正規化を緩めるかという話になりますが、
これらオプションの種類は管理者が別の管理画面にて追加、削除ができる。
という事ですから、マスタは正規化した状態が良いかと思います。
悩ましいのはトランザクションテーブルですね。
配列に関する関数[array_agg()やunnest()等) が充実しているpostgresであれば、設計のように配列でも良いかと思います。(正規化して別テーブルにする場合はキーによるリソースの問題や性能面も考えなければなりませんので。)
尚、正規化した状態の設計でも、array_agg()を使用すれば配列に畳むことも出来ますので、画面側で制御する事も可能かと。
投稿2022/06/07 04:26
編集2022/06/07 04:26
総合スコア25173
回答ありがとうございます。
この場合って正規化は可能なのでしょうか？
「サイズ」と「箸」が固定であればそれぞれの組み合わせテーブルが用意できますが、動的にオプション数が増える、変更できるとなると対応させるにはこの方法では無理かと思いますし。。。
オプションなどで使われるものとして、配列型の他にjson型などもあります。
これらは可変な項目数を一つのカラムに畳むことが出来ます。
正規化の有無によってあまりにも件数に差異が出るような場合、大量に処理するようなケースでは性能に影響しますので、正規化を緩めた方が良いと個人的には思います。
0
オプションテーブルに選択肢もenumなどで設定してやっても良いかもしれません
投稿2022/06/07 05:17
総合スコア114779
0
注文テーブルに商品idを持たせていないことが気になりますね。
商品idを注文テーブルに持たせたならば、
注文詳細テーブルでは
注文id、商品id、(商品id由来の)オプションid
でユニークになるようにして、
オプションに対する名前？値？を持てばよろし。
投稿2022/06/07 04:25
退会済みユーザー
総合スコア0
回答ありがとうございます。
> 注文id、商品id、(商品id由来の)オプションid
> でユニークになるようにして、
これがちょっと理解できていないのですが、オプションは各オプションの組み合わせがあるのでユニークキー群に含めるのが難しい気がするのですが、全組み合わせのテーブルを作るということですかね？
あなたの回答
tips
プレビュー
