Reputation: 1311
So I've searched quite a bit on implementing this and can't seem to find a best practice for how to structure my database.
I'm creating an iOS app using Firebase's new database Firestore.
Essentially I have two main 'collections'.
'users' 'locations'
There are 100 locations. Users are infinite. Users can 'like' locations. Users can 'follow' other users.
Where I'm running into an issue is querying for the currentUsers 'liked' locations and 'followed' users.
Should these be objects within the user? for example...
/users
/userId
name:"Phil"
likedLocations
location1:true
location5:true
followedUsers
userId3:true
userId6:true
Or should these be in the 'locations' collection...
/locations
/locationId
name:"New York"
userLiked
"userId":true
For ease of editing I may go in manually to the database and edit a Location. With Option A - that's no issue. Users have a possibility of having 100 items in their 'likedLocations'. With Option B - a location could have infinite (as many users as in the app) key value pairs.
Upvotes: 0
Views: 620
Reputation: 85
Why don't you use these two root collections?
/likedPlaces
/userId
name: "Phil"
location: locationId
/followers (or followed. Based on your query needs)
/userId
name: otherUserId
This way a certain user can query :
all his liked places
filter for some of them
all his followers by their id
check if a user is his follower.
Does it make sense? Hope it helps. Alessandro
Upvotes: 1