Votre schéma a l'air parfaitement bien, vous pourriez voir que les autres (y compris moi aujourd'hui) sont venus avec plus ou moins la même structure avant (Stocker les messages de différents chats dans une seule table de base de données , Schéma de base de données pour les discussions individuelles et de groupe , Création d'un thread privé système de messagerie comme facebook et gmail ). J'aimerais vraiment noter que votre représentation visuelle est la meilleure de toutes, elle est si facile à comprendre et à suivre :)
En général, je pense qu'avoir "room" ("chat", "conversation") a du sens même si vous n'avez pas de propriétés spécifiques pour le moment (comme cela pourrait être name , posting_allowed , type (c'est-à-dire si vous réutilisez la structure similaire non seulement pour les messages privés et les chats, mais c'est-à-dire pour les publications publiques avec commentaires) et ainsi de suite. Une table unique avec un seul ID d'index devrait être super rapide et avoir une surcharge proche de zéro, mais elle permettra une extension assez facilement sans avoir besoin de modifier tout le code existant (c'est-à-dire qu'un jour vous décidez d'ajouter un name aux chats). Garder la logique roomID "cachée" à l'intérieur des participants table ne sera ni transparente ni efficace (c'est-à-dire lorsque vous devez trouver le prochain identifiant du chat), je ne le recommanderais pas.
