LoginSignup
@zeijaku
Q&A

条件を追加した場合のテーブル設計について

解決したいこと

データベースをどう変更するのが良いか?

現在、商品テーブルがあり

商品番号,商品名,価格

というシンプルな内容です
今の状態であれば誰でもこれらの商品を購入可能です

これにさらに条件を追加して、Aさんは購入可能、Bさんは購入不可(他にも多数の人がおりそれぞれ条件は異なる)というような条件を追加する場合
新たに購入可否テーブルを作成し、

Aさん,商品番号1,購入OK or NG

というような形にするか、既存の商品テーブルに購入可能人物の項目を追加するか考えております。
既存の商品テーブルに追加はスマートでは無い気がしておりますが、新たにテーブルを作成した場合に上記のようなものだと
煩雑になりすぎる気がしています。
この場合、Aさんがどの商品を購入出来るかどうか?を商品数分のレコードが必要になるかと思いますが、かと言って1レコードに収めようとした場合、商品が追加された場合なども考えると1カラム内にどのように収納すれば良いか?という疑問点が出てきます。

データベースに設計には正解があるわけではないと考えておりますが、こういった場合にどういった手段が他にもあるのか?
もしくはよくある王道パターンのようなものがあれば知りたいと考えております。

自分ならこうする、もしくはこういう場合はこれで解決しているなど、何でも構いませんので考えを知ることが出来ればと思っております。

1
5
Answer

新たに購入可否テーブルを作成し

で良いんじゃないでしょうか
王道ですね

もしくはDBに権限を残さずプログラム側のロジックで実装するか

0

既存の商品テーブルに購入者情報のフィールドを加えるのは悪手でしょう。購入者は増えたり減ったりするのではないですか?
商品+購入者をキーをとしたテーブルで購入できる人はレコードがあれば良いと思います。煩雑さという点では、商品テーブルを拡張する方がいろいろ面倒そうです。

0
購入者は増えたりします
購入者が固定の場合であれば別かもしれませんが、やはり商品テーブルへの追加は悪手だろうなとは思っております

商品番号,商品名,価格
の商品番号は1品の為に付番され、販売されれば、二度と利用されることの無いコードですか?

JANコードでなければ、

商品番号,商品名,価格,取置顧客コード、手付金、有効期限

JANコードであれば

商品番号,商品名,価格,数量

手付販売、取置販売の場合でも、在庫引当するため、数量から減算し、他のテーブルに移管しましょう。

id,有効期限,商品番号,数量,取置顧客コード、手付金

入札条件は顧客側と商品側に

商品番号,条件1、条件2・・・
顧客コード、条件1、条件2・・・

マッチングアプリのようなもの?

0
商品自体は何度でも購入が可能です
Aという商品をAさんは購入できるがBさんは購入できない
購入者は追加されることもあるのでCさんは~という風に増えますが、Aという商品自体は何個もある(同じ規格のコップとか鉛筆などを想定してもらうと分かり易いかもしれません)ので消えることはありません

私も「購入可否テーブルを作成する」が良いと考えます。
デフォルトが全員購入可能なのか全員購入不可なのかによりますが、一旦デフォルトは購入可能という要件であると仮定して進めます。
その際の設計方針ですが以下の案が考えられます。

  • 購入不可テーブルにする
  • JSONで保持する

デフォルトが全員購入不可なのであれば購入可能テーブル、購入可能ユーザーリストと読み替えてください。

購入不可テーブルにする

カラム

  • 商品番号
  • ユーザー名(ユーザーID?)

運用方法

注文不可にする場合

当該テーブルにレコード追加

注文可能にする場合
  • レコードを追加しない
  • レコードがある場合削除する
注文可否の確認

existsで検索する

JSONで保持する

商品番号に対してレコードは常に1件になるように設計します。

カラム

  • 商品番号
  • 購入不可ユーザーリスト(JSON型のカラムにする)

運用方法

注文不可にする場合

当該テーブルの購入不可ユーザーリストに追加

注文可能にする場合

当該テーブルの購入不可ユーザーリストから削除

注文可否の確認
  • MySQLの場合
    • JSON_CONTAINSで検索
  • PostgreSQLの場合
    • ->で検索
  • その他:自分で調べてください
  • アプリ側(プログラム側)でJSONパースして処理
0

こんにちは
Aさんは購入できてBさんは購入できないというのは、特に条件なく管理人がこいつは購入させないって考えて購入の可否を決めてるんでしょうか?
であればみなさん言っているように購入可否テーブル作成するのがいいと思います
が、別に何か条件(Aさんはプレミアム会員だから購入OKみたいな)があるなら、

  • ユーザーと条件のテーブル
  • 条件とその条件であれば購入可能な商品のテーブル
    が必要かなと感じます
    違ったらすみません
0
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login