Su esquema se ve perfectamente bien, es posible que vea que los demás (incluido yo mismo 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 , Crear un hilo privado sistema de mensajería 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 "sala" ("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), y así sucesivamente. La tabla única con el ID de índice único debería 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 los chats). Manteniendo la lógica de roomID "oculta" dentro de participants la tabla no será transparente ni eficiente (es decir, cuando necesite encontrar la siguiente ID del chat), no lo recomendaría.
