[SOLVED] Database Relationships
Coming from Firebase, I have a hard time figuring out the database model for my App. Collections I already have:
- store (eg. grocery store)
- profiles (public user profile)
- addresses (where store is located)
- reviews (store reviews)
Relations are simple:
- Store has one Address. Ideally, address is nested in Store (currently it's working on version 1.4 using one to one relationship)
- Store can have many reviews. Each review must have an author (Profile). Each profile can have many reviews for different stores. Each reviews contains information about store its referring to.
How would you implement that kind of relationships? Using new relationship attribute in 1.4, I have issues with receiving nested documents when I don't want them (eg. displaying list of stores always gives me an array of reviews, with nested profile, per each store in list)
Should I just keep an id of a document and fetch it manually? When to choose relationship and when do it manually via id? Thanks in advance.
Each review has a store ID associated
Don't use relationships for that
Instead, just a document field (string) with the store ID
So what is the ideal use case for relationships? Store & Address, right?
Isn't that like a label?
Label? Could you elaborate?
A store doesn't have an address?
If so, then in the store document, just add an address attribute
So in my opinion this is how your database should be organised:
A main database (for example called main)
- Store collection: Each document has these attributes: Name (string), Address (string)
- Reviews collection: Each document has those attributes: Creator ID (reviewer) (string), Store ID (the ID that corresponds to the first collection document (the corresponding store document), Review ranking for example (1/10) (int) and the review text (string)
- Profiles: User name (string) and use the document ID as the user ID in Account/Auth API. You can add other fields for things like profile picture, bio, etc
@dch09 Is that helpful?
yes! that's helpful thank you
i referred to Address as a separate collection, because it's more complex than simple string.
that being said, it still could be stored as an attribute inside Store, but using new reference option right?
What do you mean?
well it's a structure, containing multiple fields
I think it should be fine unless you need to do complex queries, etc based on such data.
noted. thanks again! π€
Also, forgot to mention, if you're going to make something like only getting addresses, then it's better a separate collection for that
Can I mark this as solved, or do you need something else related to this?
sure, I think I know everything I need!
[SOLVED] Database Relationships
