I am designing a Firestore Database and am wondering about the cost implications of the following architecture...
Following cloud Firestore tutorials, lets imagine this architecture: A 'Restaurants' Collection has a 'Reviews' subcollection. Something like:
--Restuarants
--My Restaurant
--Reviews
--My Review 1, through n
I am interested in querying the reviews subcollection, but I am not really interested in the review itself, but on the restaurants.
So, for instance, in a query like Get all reviews posted on August 1st 2019
I am actually interested in the restaurants that have at least one review posted on August 1st 2019. ie. I would like to get back the restaurants' documents, not the reviews.
From this post and this it seems like my implementation would probably look something like this:
QuerySnapshot myQuerySnapshot = await Firestore.instance.collectionGroup('reviews')
.where('reviewDate', isEqualTo: '20190801').snapshots().first;
List<DocumentSnapshot> myDocumentSnapshots = myQuerySnapshot.documents;
myDocumentSnapshots.asMap().forEach((index, son) {
snapshot.reference.parent().parent().get().then((parent) {
print("Printing snapshot: $index");
print("son id: "+son.documentID);
print("parent id: "+parent.documentID); //I could then retrieve the parent data.
});
});
With this implementation, I would be fetching all the 'sons' (ie. all the reviews). This has a couple of disadvantages:
- Cost. A restaurant may have, say, 1000 reviews posted on august 1st 2019; I would be charged for 1001 reads (1000 reviews + the actual parent document I am interested in).
- Data consumption. My users would retrieve way more data from the servers than what is actually needed.
Is there a better way to do this? Is there a way to avoid fetching the reviews and getting only the parent documents?
Thanks!
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…