Not directly about Thunkable, but if you’re putting data in Firebase, definitely relevant!
I’m not a database expert, but I’ve spent just enough time with relational databases that some of my instincts are just /wrong/. I’d not have thought to do the last example because it feels like storing the data twice, but looking at it, I’m like “oh yeah, that would be so much easier to access!”
I like the index of groups idea presented on that site. I found that structuring Firebase around a User ID (generated at Sign Up) kept all data separate and prevented the problem they describe of downloading extraneous data.
I similarly have user data under a user ID. I do definitely need an index. Not addressed (more to learn!) is how to work the permissions in this situation.
@jared , yes thanks, I understood that, but it may be useful for someone else! (And I apologize, I haven’t watched the video yet - maybe you answered it there. My laptop is having sound issues.)
What I was saying above was that if in addition to a /users/ bucket I also needed a /groups/ bucket with structure /groups/groupA/members/(list of members) that I was less sure how to lock those permissions down. (Let’s suppose we let members join groups themselves. I’m thinking it’s just some clever wildcard use to make sure they’re only adding themselves, but I haven’t worked it out or found a really good example of it – yet.
