Reputation: 47921
In the firebase realtime database, you would normally move large subcollections out into a separate collection of its own. For instance, if a user might have a large number of followers, the data model might keep following array in the user object, but move the followers out to a separate collection.
Would you have to do the same kind of modeling with the new Cloud Firestore, or can you use projections in your query so that you aren't returning a large sub-collection with every scan. It sounded like sub-collections are stored in their own full collections so this might make it more efficient in storing sub-collections?
Upvotes: 3
Views: 864
Reputation: 7870
Firestore allows either structure. For most operations once you throw network latencies into the mix neither is observably more efficient than the other.
Unlike the Realtime Database, queries in Firestore are shallow by default, so if you did nest followers within users, querying for a user doesn't require loading all their followers. This means you don't have to store followers separately.
In the subcollection structure, you could also make use of collection group queries to query across all subcollections with the same ID.
Upvotes: 3
Reputation: 127024
I do not think that you have to do that at all because getting a Document
will not download others from sub collections. That said it does not really have that disadvantage it had in Realtime Database.
I could not find another source where it is mentioned in a short amount of time, so check out this video. It is the "Getting Started" video for Android and about 40 seconds in (from the time stamp provided in my link) he mentions exactly what I said and Todd Kerpelman's statement: "[...] it's very common to see a collection containing a bunch of documents, which then point to sub collections that contain other documents and so on.", basically implies that the team expects this type of data storing.
Upvotes: 3