Looking at this video, it has a tasks collection and it clones/denormalizes all the completed tasks inside its own collection.

As a result, it will have 2 collections: tasks and completedTasks.

I know denormalization is recommended in NoSQL type of databases and we have to optimize for database reads. I have a couple of questions to ask about this approach.

1. As far as I know, Firestore bills you with the number of result-set not the number of documents it reads.
2. Secondly, based on the first point, why not simply filter it by completed property instead of creating a totally separate completedTasks collection. In any case, both will return the same number of documents and both will have the same amount of reads? Am I missing something here?

With this approach, aren't we saving DB writes and preventing database update/delete anomaly?

CodePudding user response：

As far as I know, Firestore bills you with the number of result-set not the number of documents it reads.

It's exactly the opposite. You'll be charged with a number of document reads that are equal to the number of documents that are returned by your query. It has nothing to do with how large your data set is. Let's say you have a collection of 1 million documents, but your query only returns 10 documents, then you'll have to pay only 10 document reads.

While you're online, if you perform two queries that return the exact same documents, you'll be charged twice. I have even written an article regarding this topic:

• How to drastically reduce the number of reads when no documents are changed in Firestore?