目的
ユーザと店舗とのチャットアプリを実現するDB設計を行います。
1対1のメッセージアプリではなく、以下のような1対Nの特徴があるチャットアプリを考えたいと思います。
ユーザーは商品を通した店舗ごとにメッセージをやりとりすることができ、店舗は商品ごとに別れたチャットでユーザーとやりとりができます。
なお、ここでは全てRDS上で完結する構成で考えます。
ER図の作成
登場人物を考える
ユーザと店舗とのチャットアプリを考える上で、最低限、必要な登場人物は以下になりそうです。
- 店舗
- ユーザー
店舗
ここでは、名前, アイコン を持たせます。
▼shops（店舗テーブル）
ユーザー
同様に、名前, アイコン を持たせます。
▼users（ユーザーテーブル）
他に必要なEntityを考える
チャットアプリというからには、メッセージとトークルームも必要そうです。
そして、今回は「商品ごとに説明を聞ける部屋」があるため、商品も必要になります。
- 商品
- メッセージ
- トークルーム
商品
商品名, 画像, 店舗ID があれば良さそうです。
▼items（商品テーブル）
メッセージ
チャットを通じてやりとりを行うメッセージです。
「誰が誰に送信したか」「どの部屋で、どの商品についてのやりとりか」が必要になるため、以下のようなカラムが必要になりそうです。
- ユーザーID, 商品ID, 店舗ID. 部屋ID, メッセージ本文, 送信元, 送信先
ここで送信元/送信先に注目すると、今回は店舗とユーザーのチャットアプリなので、ユーザー同士・店舗同士のチャットは不要そうです。
あえてカラムを2つにする理由もないため、送信元/送信先は番号（1:ユーザー, 2:店舗）で持たせます。
▼messages（メッセージテーブル）
部屋
部屋名, 商品ID, ユーザーIDが必要になりますが、
「店舗は、個別の商品ごとにユーザーとやりとり」を行える必要があるため、「ユーザーが利用する部屋」と、「店舗が利用する部屋」とで異なるEntityを作成したいと思います。
また、ここではLINEのようにメッセージごとの状態を持たせ、 既読/未読/返信済 のステータスを持つものとして考えます。
ステータスはメッセージごとに存在するため、一見メッセージに持たせようと考えましたが、実運用としてトークルームごとの最新メッセージに状態があれば良いため、チャットルームごとに持たせる設計としました。
▼rooms（ユーザー視点のチャットルームテーブル）
▼shop_room（店舗視点のチャットルームテーブル）
ER図
最後に、これらをまとめると以下のような設計となります。
以上、1対Nの特徴があるチャットアプリでのDB設計についてでした。
ユースケースとしてユーザーと店舗での利用の仕方はどうなるかを考えつつ作成したため、こうした方が良い等あれば是非コメント頂けると嬉しいです。
そもそも、メッセージ自体RDSに保存させるのは負荷になるという点も懸念ではあるため、合わせてご指摘頂けると幸いです。