2020/02/13SHAREツイートシェアはてブGoogle+PocketLINEここでは、初心者から実践的に学べるプログラミングスクール「ウェブカツ!!」のWEBサービス部を受講している生徒の方向けにさらに「データベースのテーブル設計」についての理解度を上げるため特訓をしていきます。ここでは「MySQL」を題材にします。売り手にも買い手にもなる場合DBのテーブル設計鬼練11:売り手と買い手をどう管理する?問題ユーザーにも種類がある場合がありますね。楽天市場みたいに「売主」と「買主」が別々でいるようなケースです。下記の問題に答えてください。ユーザー情報の中でも、売主と買主が判別できるようにテーブルを設計してください。ヒント前回、グループで管理者と一般ユーザーを識別しましたよね??答え答えはですね。前回と全く変わらないです。グループカラムで識別出来るからです。管理者を「3」みたいにですね。管理者を「2」みたいにした場合、今回のように一般ユーザー以外のユーザー種別が出来た時どうする?ってことになるわけです。売主ユーザーを「4」みたいにすればいいわけですが、ここもセキュリティリスクがあります。番号的に管理者が「2」に来るのが気持ち悪いというものもあるんですが、もしユーザー情報を管理者なりが手でphpMyAdminなどからユーザー作成する場合を考えてみてください。人って入力間違いをする生き物ですよ?誤って「3」と入れるはずのグループを「2」と入れる危険性ないですか??もしそれでユーザー作ったら、そのユーザーの人は管理者の全権限で全員の個人情報見れたりするかもしれませんよ?一気に情報漏洩もんですね。(まぁ、実際は管理者と言ってもさらに「ここまで見れる、使える」という「権限」をさらに細分化してる事がほとんどですし、そもそも手でユーザー作るようにしない方向で運用をしていくのが普通ですけどね。「無料ユーザー、有料ユーザー」という区別だってありそうですね。言えば、有料ユーザーの中でもいくつかのプランがあったりするわけです。「◯◯プランユーザー」「△△プランユーザー」みたいなのをどうユーザー情報から識別するんでしょ?各プランに応じて表示するコンテンツなり、使える機能なり制限しなきゃいけないですよね。同じ「ユーザー情報」の中からどう識別するんでしょ??だから「グループ」みたいなカラムが必要になるわけですね。テーブルを分ける事も考えようちなみに楽天市場のように「売り手」と「買い手」でそもそも保存する情報がかなり違う場合があります。売り手が店舗だったり法人で、買い手は一般消費者みたいなパターンのサービスだとそもそも保存するカラム(保存しておく情報)が大きく異なる事もあります。いう場合はテーブルを分ける事も考えましょう。一般ユーザーテーブル(users)店舗テーブル(shops)みたいなテーブル構成になりますね。どっちも同じ「サービスを使っている人(ユーザー)」ではあるけども、あえて分けている。これもまた今までの話のように「users」テーブルに全部店舗ユーザー用に保存するカラムを作っておいて、一般ユーザーの場合はその店舗情報系のカラムは空にしとく「group」カラムで一般ユーザーが店舗ユーザーかを判別させるなんてやり方ももちろん出来なくはないし、そうやっているサービスもありますし、悪いということもありません。逆にメルカリのように一人のユーザー(ユーザー情報)が「売り手にも買い手にもなる」なんてサービスもあります。その場合は、もちろん今までのテーブル構成と全く同じでユーザーテーブルに普通に全てのユーザーの情報を保存しておく売り手になりたい人(商品登録をしたユーザー)は商品テーブルに商品情報を保存するだけでいいわけです。商品情報があるユーザーは少なからず「売り手」であり、買い手の可能性もある(売る専門で使っているユーザーもいるので)という事がDB上だけで判断できるわけですからね。卒業試験に関する仕様変更と利用規約変更のお知らせ顧問プロフィールかずきちプログラミング学習サイト「ウェブカツ!!」の顧問。不動産、保険の営業マンから、エンジニアへ転身。「HTMLって何?」という状態から3ヶ月の独学のみでエンジニアへ転職し、1年で年収1千万を稼ぐエンジニアへ。独学時代のプログラミング学習の分かりにくさや、「技術しか出来ずに稼げていないエンジニア」の現状を変えるため「ウェブカツ」を立ち上げ運営している。