実際は「これから作るサービス(もしくは既にあるサービスに追加する機能)」からDBへ保存しておく必要のある情報を洗い出す必要があります。「DBへ保存しておく必要のある〜」ってところです。DBのテーブルを設計するわけですから。DBに保存する情報は何か?を洗い出してるわけですからね。実際は「サービスに必要な登場人物」を洗い出したら、そのサービスに必要な情報を次に洗い出します。サービスに必要な情報の洗い出し方サービスに必要な情報には大きく2種類があり、サービスで表示させるために必要な情報(ユーザーが見れる「表側」の情報)サービスの管理のために内部で必要な情報(管理者しか見なかったり、サービスを運営するために内部だけで必要になる「裏側」の情報)があります。「表と裏」の情報があるわけですね。表側の「表示するための情報」は、WEBサービス部でやってる「画面設計」で画面のワイヤーフレームを作っていくと分かっていきますよね。「あ、ここにこの情報表示したいな。ことは、この情報を登録してもらわないとな。」っていう感じにですね。先に画面設計して「視覚化」していった方が情報が洗い出しやすくなります。(慣れてきちゃえばさほど項目数がないものであれば頭の中でワイヤーフレームが思い浮かぶので、頭の中だけで必要な情報がパパッと洗い出せていきます。情報を表示、非表示にするために区別するためのフラグ削除された情報なのかどうかのフラグ(delete_flgのようなカラムですね。)とかそういったものです。(ブログの記事だったりなら、「登録された日時」も画面に表示したりしますけどね)あとはテーブルを結合する時に必要な「外部キー」であったりですね。(ここらへんもあとあと詳しくやります)DBに保存すべき情報かを洗い出す情報を洗い出した上で、DBに保存すべき情報か?を見極めていきます。ウェブカツのTOPページにあるような「入部者の声」というものはDBに保存しておく必要ありますかね?分かってると思いますが「ない」ですよね。htmlに書いてしまえばいいわけですから。DBに保存をしておいて、その保存した入部者の声を表示するということも出来るわけですが。基本的にDBへ保存をする情報というのは永続的にしたいもの(ずっと保存しておきたい)更新頻度の高いものブラウザなど閲覧するツールが変わっても同じように表示したいもの(「セッションに保存する」という方法もありますが、これはブラウザ自体に保存されるので別ブラウザで見たらダメですよね)ユーザーのものユーザー自身に操作させて情報を操作させたいものを保存します。入部者の声の情報というのはそもそも「運営側」のものであって、「ユーザーのもの」ではないですね。ユーザーが入部者の声を勝手に更新できたら困りますよね。PCで見ても、スマホで見ても、ブラウザを変えて見ても同じく表示させたいですが、それなら「HTMLで書く」だけでも同じですね。入部者の声が日々変わりますか?常に更新されるものですか?日々更新されるとしても、htmlを変えればよくないですか?わざわざDBに保存しておいて、DBから取得してhtmlとして表示させる処理コードを書くよりも、htmlで書く方がはるかにメンテナンスが楽ですし、誰が担当しても修正できますよね。(しかも、「DBへの通信」がその分発生するわけなのでサイトが表示されるまで重くなりサイトパフォーマンスも悪くなりますね。)わざわざDBの中に入って、更新なんてしてたら面倒ですよね。DBへ入る方法をWEBの担当者に教えるんでしょうか?皆その方法を分かってる必要ありますね。そもそも、会社の人であったとしても勝手にDBの中に入れてしまっては危ないですよね、個人情報も大抵ありますし、変な操作されてデータ消されたら大変です。したら、DBを管理画面上から更新できるように管理画面を作りますか?わざわざ?しませんよね。これは極端な例ですが、そういう判断をしていくわけです。他にも今回の場合であれば「パスワード(確認用)」というユーザーに入力してもらう情報はDBに保存する必要はないですよね。入力されたパスワードがユーザーが入力間違いしてないかをユーザー登録する前(DBへ保存する前)にチェックするためだけのものですから。通販カートの情報はDBへ保存すべきか?ちょっと話変わりますが、他にも例えば「通販サイト」であればカートに商品を保存するって機能ありますよね。「商品を購入する」ボタンを押した時によくあるやつですね。いった「あるユーザー」が、「ある商品」をカートに保存したという情報はどこに保存しましょう?ここらへんは「サイトによる」んですが、DBに保存するセッションに保存するの両方があります。WEBサービス部でもやりましたが、セッションは「ブラウザ自身」に保存しておくものです。あるユーザーでログインをしていて「カートに保存」した後に別のブラウザでログインをしたとしてもそこのカート内には保存された情報はありません同じブラウザにしか保存されてませんからね。昔はこういうカート機能が結構ありました。今も個人サイトみたいな規模の小さなサイトであったりします。出かけ先でスマホでログインして見てもちゃんとカートに保存されたままですよね。いうのはDBに情報を保存する方法でしかできないわけです。「shopping_cart」みたいな名前のテーブルを作ってそこにユーザーがカートに保存を押すたびに「誰が」「何の商品を」「いつ」「いくつ(個数)」といった情報を保存しとくわけですね。実際には「誰が」にはユーザーの氏名や住所や連絡先やらといった情報もあり、「何の商品を」には商品名やら、商品詳細、金額やらといった情報もありますが、それは「shopping_cart」テーブルに保存することはしません。(ここらへんは「正規化」と呼ばれるものでしたね。ここらへんもあとあとまたやります)ちょっと脱線しましたが、こういったように表と裏の情報を洗い出すその情報の中でDBに保存をしておいた方がいいものをピックアップするということをやっていくわけです。け「DBのテーブル設計鬼練7〜メルカリの商品情...顧問プロフィールかずきちプログラミング学習サイト「ウェブカツ!!」の顧問。不動産、保険の営業マンから、エンジニアへ転身。「HTMLって何?」という状態から3ヶ月の独学のみでエンジニアへ転職し、1年で年収1千万を稼ぐエンジニアへ。独学時代のプログラミング学習の分かりにくさや、「技術しか出来ずに稼げていないエンジニア」の現状を変えるため「ウェブカツ」を立ち上げ運営している。