ここでは、初心者から実践的に学べるプログラミングスクール「ウェブカツ!!」のWEBサービス部を受講している生徒の方向けにさらに「データベースのテーブル設計」についての理解度を上げるため特訓をしていきます。
ここでは「MySQL」を題材にします。
目次
DBのテーブル設計鬼練１１：売り手と買い手をどう管理する？
問題
ユーザーにも種類がある場合がありますね。
楽天市場みたいに「売主」と「買主」が別々でいるようなケースです。
下記の問題に答えてください。
ユーザー情報の中でも、売主と買主が判別できるようにテーブルを設計してください。
ヒント
前回、グループで管理者と一般ユーザーを識別しましたよね？？
答え
答えは
ですね。
そう、前回と全く変わらないです。
なぜなら、
グループカラムで識別出来るから
です。
- 売り主ユーザーを「1」
- 買主ユーザーを「2」
- 管理者を「3」
みたいにですね。
番号とセキュリティリスク
ただし、前回もちょっと最後に話したように最初から
- 一般ユーザーを「1」
- 管理者を「2」
みたいにした場合、今回のように
一般ユーザー以外のユーザー種別が出来た時どうする？
ってことになるわけです。
もちろん、
- 一般ユーザー（無料登録的なユーザー）を「1」
- 管理者を「2」
- 買主ユーザーを「3」
- 売主ユーザーを「4」
みたいにすればいいわけですが、ここもセキュリティリスクがあります。
ただ番号的に管理者が「2」に来るのが気持ち悪いというものもあるんですが、もしユーザー情報を管理者なりが手でphpMyAdminなどからユーザー作成する場合を考えてみてください。
人って入力間違いをする生き物ですよ？
誤って「3」と入れるはずのグループを「2」と入れる危険性ないですか？？
もしそれでユーザー作ったら、そのユーザーの人は管理者の全権限で全員の個人情報見れたりするかもしれませんよ？
一気に情報漏洩もんですね。
（まぁ、実際は管理者と言ってもさらに「ここまで見れる、使える」という「権限」をさらに細分化してる事がほとんどですし、そもそも手でユーザー作るようにしない方向で運用をしていくのが普通ですけどね。そこらへんまた次回以降で）
様々ユーザー種別
「売主、買主」以外にも、「無料ユーザー、有料ユーザー」という区別だってありそうですね。
もっと言えば、有料ユーザーの中でもいくつかのプランがあったりするわけです。
「◯◯プランユーザー」「△△プランユーザー」
みたいなのをどうユーザー情報から識別するんでしょ？
各プランに応じて表示するコンテンツなり、使える機能なり制限しなきゃいけないですよね。
同じ「ユーザー情報」の中からどう識別するんでしょ？？
だから「グループ」みたいなカラムが必要になるわけですね。
テーブルを分ける事も考えよう
ちなみに楽天市場のように「売り手」と「買い手」でそもそも保存する情報がかなり違う場合があります。
売り手が店舗だったり法人で、買い手は一般消費者
みたいなパターンのサービスだとそもそも保存するカラム（保存しておく情報）が大きく異なる事もあります。
そういう場合はテーブルを分ける事も考えましょう。
（じゃあ、どれだけ情報が違ったら分けるの？というのは、ここらへん難しい話なので、現場で話し合うしかありません）
そういう場合
- 一般ユーザーテーブル（users）
- 店舗テーブル（shops）
みたいなテーブル構成になりますね。
どっちも同じ「サービスを使っている人（ユーザー）」ではあるけども、あえて分けている。
ってなわけです。
まぁ、これもまた今までの話のように
- 「users」テーブルに全部店舗ユーザー用に保存するカラムを作っておいて、一般ユーザーの場合はその店舗情報系のカラムは空にしとく
- 「group」カラムで一般ユーザーが店舗ユーザーかを判別させる
なんてやり方ももちろん出来なくはないし、そうやっているサービスもありますし、悪いということもありません。
売り手にも買い手にもなる場合
逆にメルカリのように
一人のユーザー（ユーザー情報）が「売り手にも買い手にもなる」
なんてサービスもあります。
その場合は、もちろん今までのテーブル構成と全く同じで
- ユーザーテーブルに普通に全てのユーザーの情報を保存しておく
- 売り手になりたい人（商品登録をしたユーザー）は商品テーブルに商品情報を保存する
だけでいいわけです。
商品情報があるユーザーは少なからず「売り手」であり、買い手の可能性もある（売る専門で使っているユーザーもいるので）
という事がDB上だけで判断できるわけですからね。
