要約
現在作成しているアプリで実装予定の機能の一つに、DM機能があります。
しかしそのための論理設計（DB設計）の過程で、なぜエンティティとしてメッセージルームが必要なのか、理解するのに時間がかかりました。
結論として、自分は手書きでテーブルとレコードを作成し、どんなエンティティが必要かイメージすることで解決できました。
本記事はこんな人におすすめ
- DB設計でエンティティの抽出に苦戦している方
- DB設計における初心者の躓きポイントを知りたい方
なお、用語やそもそもの理解に誤りがあるかもしれませんが、どうか生暖かい目で見守っていただけますと幸いです。
問題
- DM機能のために必要なテーブルが分からない
- usersテーブルとmessagesテーブルの他にmessage_roomsテーブルも必要だと言われたが、なぜ必要だか理解できない
- よっておそらく、DB設計の体系的知識がない
アプローチ
まずDM機能に必要なテーブルは何か、LaravelDB.comを使って考えてみました。
DM要素には「usersテーブル」と「messagesテーブル」が必要で、そんで中間テーブル「user_messages」を用意して…
という思考だったと思います。
しかし今見てみると、そもそも「多対多」のリレーションがないのに、なぜか中間テーブルを用意しています。
この時点で有識者にフィードバックを求めた所、
『この設計だとメッセージをユーザーが送信することはできますが、誰が受信するかが分からない設計になっています』
とヒントを頂きました。
しかしそこから手が進まなかったので、一度基本的な部分を勉強することにしました。
教訓①
「理解することをサボらない」
少しの遠回り
そこで『達人に学ぶDB設計徹底指南書』を読み、インプットとアウトプットを行うことで解決を図ります。
その結果、なんとなく『「論理設計」の中のエンティティの抽出がうまくいっていないのではないか？』と、勘所を見つけて解決することができました。
少し時間はかかりましたが、結果としてDB設計の全体像を少し掴めた気がします。
解決への道
再度エンティティの抽出からやり直した結果、今のままだとuserとmessageが割り当てられる場所がないことに気づきました。
そこで、新たに「message_rooms」テーブルを設置。
そしてユーザーとメッセージルームの「多対多」のリレーションを仲立ちする中間テーブル「message_room_user」も必要でした。
最終的な完成図は以下の通りです。
解決に至っては、以下のように手書きでテーブル内のレコードを書き、イメージしてみるという手法も有効でした。
（冗談抜きで汚くてすみません・・・）