Hi Chris, thank you for your response. That makes more sense to go with a Join, I agree with you, thanks for taking the time to answer!
When showing the list of chatrooms (chatrooms#index), I would like to display the usernames of the users in that room along with the name of the room.
Do you think this would be a good use case for a array/jsonb column type in the chatrooms, in order to store information about the users subscribed to that chatroom?
That would avoid extra table joins on the users table, but would have the downside of needing to update the chatrooms when a user updates his username.
The alternative would be to go with a regular table join on the users table when fetching the chatrooms.
Thanks for your feedback on this.
Thanks for your answer Chris. I agree with you, I will try to solve this issue once and if I face it!
Thank you Chris for a very interesting video. This Notification model works great for scenarios where notifications are created one at a time (actor to recipient action), or the way you use it with gorails.com to notify users a couple times per week. I would like to use this Notification model to notify users whenever (using this example) a new forum thread is created, or other actions are made among a group of users, thus being notified individually. Meaning every time a new forum thread is created, hundreds of users could potentially be notified, and this could grow very quickly if I want to add other actions to notify users. There is another approach making this kind of frequent multi-users notifications a public activity model https://github.com/chaps-io... but then you loose the individual read indicator or any individual metadata. Can you think of a way to keep the episode database structure for notifications, to scale it for a scenario of large notification creations?