あなたのスキーマは完全にうまく見えます、あなたは他の人（今日の私を含む）が以前は多かれ少なかれ同じ構造を持っていたのを見るかもしれません（さまざまなチャットのメッセージを単一のデータベーステーブルに保存する 、1対1およびグループチャットのデータベーススキーマ 、スレッド化されたプライベートの作成FacebookやGmailなどのメッセージングシステム ）。私はあなたの視覚的表現が何よりも優れていることに本当に注意したいと思います、それはとても理解しやすく、従うのが簡単です:)
一般に、現時点で特定のプロパティがない場合でも（nameの場合もあるため）、「部屋」（「チャット」、「会話」）を持つことは理にかなっていると思います。 、posting_allowed 、type （つまり、プライベートメッセージやチャットだけでなく、コメント付きの公開投稿にも同様の構造を再利用する場合）など。単一のインデックスIDを持つ単一のテーブルは超高速でオーバーヘッドがゼロに近いはずですが、既存のすべてのコードを変更することなく、非常に簡単に拡張できます（つまり、ある日nameを追加することにします チャットに）。roomIDロジックをparticipants内に「非表示」に保つ テーブルは透過的でなく、効率的でもありません（つまり、チャットの次のIDを見つける必要がある場合）。