Es fundamental interpretar el código correctamente previamente a usarlo a tu proyecto y si tquieres aportar algo puedes decirlo en los comentarios.
Solución:
Su esquema se ve perfectamente bien, es posible que vea que los demás (incluyéndome a mí hoy) venían con más o menos la misma estructura anterior (almacenamiento de mensajes de diferentes chats en una sola tabla de base de datos, esquema de base de datos para chat individual y grupal, creación de un sistema de mensajería privada en hilos como facebook y gmail). Realmente me gustaría señalar que su representación visual es la mejor de todas, es muy fácil de entender y seguir 🙂
En general, creo que tener “espacio” (“chat”, “conversación”) tiene sentido incluso si no tiene propiedades específicas en este momento (como podría ser name, posting_allowed, type (es decir, si reutiliza la estructura similar no solo para mensajes privados y chats, sino también para publicaciones públicas con comentarios), etc. La tabla única con ID de índice único debe ser súper rápida y tener una sobrecarga cercana a cero, sin embargo, permitirá la extensión con bastante facilidad sin necesidad de modificar todo el código existente (es decir, un día decide agregar un name a las charlas). Mantener la lógica de roomID “oculta” dentro participants la tabla no será transparente ni eficiente (es decir, cuando necesite encontrar la siguiente ID del chat), no lo recomendaría.
Nos encantaría que puedieras dar difusión a este escrito si te fue de ayuda.