I'm really new on Cloud Firestore, so it's a bit strange for me to structure the database.
I would like to save my workouts. If I were on RealtimeDatabase I would do something like that:
WorkoutResults | +--AutoID | | | +--date | +--userID | +--result
AND
UserWorkoutResult | +--UserID | | | +--WodResultGeneratedID |
In that way, I can only fetch one node to a specific user. But if I understand well on Cloud Firestore, it's not possible to query on subcollections.
So my question is, do you think this structure is good enough to scale?
WorkoutResults | +--AutoID | | | +--date | +--userID | +--result
By doing something like:
.whereField("userID", isEqualTo: "userIDString").whereField("date", isEqualTo: theDateIWant) ?
Your query looks fine to me. And as Firestore promises, its performance is only related to the number of matching WorkoutResults
, not to the size of that collection.
But you could get the exact same result by querying collection("Users").doc("userIDString").collection("WorkoutResults").whereField("date", isEqualTo: theDateIWant)
in your first data structure. The only thing that isn't possible there is to query across the WorkoutResults
for multiple users, since querying across multiple collections isn't possible.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.