チャット機能のデータベース構築方法

「ノーコードでどこまでできるのか」という議論がありますが
これらの多くはデータベース設計によって解決できると考えています。

今回はチャット機能のデータベース設計を考えます。
BubbleやAdaloはもちろん、Glideでも実装できるはずです。

本来リレーションが1:1、1:多、多:多と、どの関係であるかも考慮しますが、一旦は省略します。関係性だけ把握できればと思います。
また、データベース設計に正解はありませんし、ツールによって設計が変わります。あくまで一例として参考にしてください。

完成イメージ

Adaloのチャットテンプレートです。
「あぽと」と「Adalo芸人」の部屋を作成し、個別チャットが実装されています。

DB構造（簡易版）

まず、基本となる構造を図示します。
二人用のチャット部屋を作成し、メッセージを送り合います。
イメージはLINEです。

Users：ユーザー情報
Conversations：チャット部屋
Messages：メッセージ本文

ユーザーがチャット部屋を作成すると、Conversationテーブルにレコードが生成されます。
この時、チャット部屋のメンバーを、Usersテーブルと結びつけて記録します。

次にメッセージを送ると、Messageテーブルにレコードが生成されます。
この時、送信者をUsersテーブル、チャット部屋をConversationテーブルと結び付けて記録します。

こうすることで、LINEのようなチャット画面を作ることができます。
チャット一覧表示
・チャット部屋と自分（Current User）が結びついている
メッセージ一覧表示
・現在開いているチャット部屋とメッセージが結びついている
自分のメッセージは右側、相手のは左側に表示
・右寄せと左寄せの吹き出しを2つ用意
・メッセージ送信者が自分（Current User）なら右側、そうでないなら左側

DB構造（Adaloテンプレート）

Adaloテンプレートをほぼ完全に図解すると、こうなります。

ReadStatus：既読情報

チャット画面表示時および、メッセージ送信時にReadStatusテーブルにレコードが生成されます。
ユーザーにはどちらもCurrent Userが入ります。

ここまで作ると、更にこのような機能が追加できます。
未読表示
・ReadStatus作成日時が、Conversation最終送信日時よりも後
・ReadStatusのユーザーが自分自身
・上記２条件を満たさないReadStatusが0個なら未読。
部屋の管理者のコマンドを追加
・作成者がCurrent Userなら部屋名変更、削除などができる

未読表示が少しややこしいですね。
もし相手がメッセージを送ると、最終送信日時が更新されます。
すると1つ目の条件を満たすReadStatusが無くなるので未読になります。
その後チャット画面を表示すると、自分の名前でReadStatusを作成します。
すると両条件を満たすReadStatusが作成され、個数が1となるので未読表示が消えます。

もしYes-No設定があれば、これを使って切り替えると簡単になりそうですね。

簡易的でよければ、最新のメッセージを取得し、送信者が自分でなければ未読表示、という方法も可能ですね。
未読というより、未返信ですが。

ここはいろんな表現方法があるし、場合によって使い分けたいですね。

AdaloテンプレートはDB学習にオススメ

DB設計の学習は、マネをしながら数をこなすのが近道である、という話を以前にしました。

マネをする対象として、ノーコードツールのテンプレートはとても良い教材になります。

特にAdaloのテンプレートは勉強教材として最適だと思います。
テンプレートのデータ構成をマネながら理解していくと、ノーコードで色んなアプリが作れることに気づくはずです。

追記：bubbleテンプレートの場合

Adaloテンプレートを解説しましたが、bubbleの場合も同じくテンプレートから学ぶことができます。

例えば、この無料のチャットテンプレート。
https://bubble.io/template/pro-messaging-1553963324044x290031175583137800

WorkFlowまでは作り込まれていませんが、実際にDBを見るとAdaloテンプレートの構成とほぼ一致しています。
Listの仕様がbubble特有ですが、考え方はAdaloと似ています。

基本の設計さえ分かれば、他ツールでも応用できますね。