I am developing a an audio conferencing app and would be using appwrite to manage room actions, participant list etc. Will it be efficient if I create a separate database for each room ?
I don't think it's necessary to create a database for each room
I don't know what is your entities but let suppose you have a room , and each rooms have ( obviously ) participant list
You can just have a room collection and inside the room attributes you will have an array to store each users who have access to this specific room
You can also group users of a room by using teams API
And with this if there are documents which only this team should have access to you just add the corresponding permission to the document when creating
It's just some ideas on how to organize , it may be not 100% fit on what you're trying to do ( since I don't have a precise idea on the complete project )
But generally if your dB design ends up by creating new databases or collections at run-time , you're probably doing something wrong or looking in the wrong direction
Simple answer, it's not efficient
Thanks @lk_7t2 @D5 It would be helpful if you could guide me on how I can design my database.
My use case is as follows Its a clubhouse clone. There will be public as well as private audio rooms. People can join and leave on demand. The communication part is implemented separately. For room management, i.e if the user is admin or if the user’s mic is on or user’s hand is raised, we are using appwrite realtime on database channel.
Thanks @Steven
Recommended threads
- iOS Auth - Apple OAuth not working.
when i use the prod app, the apple auth on ios is not working, it shows me: missing redirect url. however the debug version, connected to another project is wor...
- Creation failedUnknown sort order:asc. M...
Hi there, I'm getting this error on self hosted when trying to create an Index. Any ideas?
- Export, Import or Migration giving this ...
As you can see in yhe screenshot i am not able to export any data or export the data from tables. Also it is affecting the migration from appwrite to appwrite h...