You are developing an application that will allow users to read and post comments on news articles. You want to configure your application to store and display user-submitted comments using Firestore. How should you design the schema to support an unknown number of comments and articles?
To design a schema that effectively supports an unknown number of comments and articles using Firestore, you should store each comment in a subcollection of the article. This approach leverages Firestore's hierarchical structure, where collections contain documents, and documents can contain subcollections. By storing comments in a subcollection of the corresponding article, you ensure scalability and efficient querying. It allows you to easily retrieve all comments associated with a specific article without the constraints of document size limitations, providing a flexible and scalable solution.
Selected: A Firestore has a “hierarchical structure”: collection contains documents, document can contain (sub)collections D does not make sense bc why do you want to link comments to the user profile instead of the article? https://stackoverflow.com/questions/48634227/limitation-to-number-of-documents-under-one-collection-in-firebase-firestore “There is no documented limit to the number of documents that can be stored in a Cloud Firestore collection. The system is designed to scale to huge data sets.”
the subcollection has a limit of 1Mb of data, so for unknown number of comments is not valid, the answer is D
That's wrong, the 1MB limit it's on the document inside the subcollection (not on the subcollection itself. "Document size - Cloud Firestore is optimized for small documents and enforces a 1MB size limit on documents. If your array can expand arbitrarily, it is better to use a subcollection, which has better scaling performance." Check out also the example in the subcollections documentation, showing a rooms-messages hierarchy example. https://firebase.google.com/docs/firestore/data-model#subcollections
Why D and not C? For my understanding, we need to keep a relation between the articles and their comments. I don't see how the user profile could come in handy... but please let me know if I misunderstood something. For me, Ans C makes more sense.
Answer is A
As per previous comments also appointed, there is not such a limitation on size for a Subcollection, and it does not make sense to store the relation with User profile like answer D
Answer is A. Store each comment in a subcollection of the article, because it allows for easy scaling and querying of the comments as the data increases. With this approach, you can easily fetch the comments associated with an article by querying the subcollection of that article, instead of querying all the comments in a single collection. It also allows you to query specific comments and articles easily, since you have the reference to the specific article they are associated with.
Storing each comment in a document, and adding the comment's key to an array property on the user profile (Option D) would make it more difficult to fetch all the comments associated with a specific article. Additionally, it would also make it more difficult to query the comments and articles since you would have to go through the user profile to find the comment's key and then use that to find the comment's information. The subcollection approach allows for better organization and querying of the data, making it a better choice in this scenario.
C. Store each comment in a document, and add the comment's key to an array property on the article would work, but it may not be the best solution for this use case. While it would allow you to query for all the comments associated with an article by finding the document with the article and reading the array property of its key. However, this approach would make it more difficult to scale the data as the number of comments grows, because it would require you to retrieve all the comment keys in the array of the article and then perform additional queries to retrieve the actual comment information one by one. This could slow down the application as the number of comments increase, and make it more difficult to handle high-load situations.
Another reason for not choosing C is that, it might also pose an issue for data consistency as comments can change over time and updating the comment document would not automatically update the array property on the article, creating inconsistencies in the data.
Option A is the recommended approach for structuring data in Firestore to support an unknown number of comments and articles. Firestore is a NoSQL document-oriented database, and using subcollections provides a flexible and scalable way to organize related data
the correct answer is A. reference: https://firebase.google.com/docs/firestore/data-model
Close to this example: https://firebase.google.com/docs/firestore/data-model#subcollections
Exactly this, thanks for sharing the docs here, I change my answer because of you!
The best answer here is A. Store each comment in a subcollection of the article. Here's why: Scalability: Storing comments as subcollections within the article document allows you to handle an unlimited number of comments per article. Firestore scales well with large numbers of subcollections. Querying: You can easily query for comments related to a specific article using the collectionGroup() query. This allows you to retrieve all comments for an article without needing to know the specific comment IDs. Performance: Firestore's subcollection structure optimizes for reading and writing comments related to a specific article.
Let's look at why the other options are less ideal: B. Add each comment to an array property on the article: This approach is limited by the maximum document size in Firestore (1 MB). You'll run into issues if you have a large number of comments for a single article. C. Store each comment in a document and add the comment's key to an array property on the article: This approach is less efficient for querying comments related to a specific article. You'd need to perform multiple queries to retrieve all comments. D. Store each comment in a document and add the comment's key to an array property on the user profile: This approach is not ideal for retrieving comments related to a specific article. You'd need to query the user profile for each comment, which is inefficient.
Firestore has a hierarchical structure
It can't be D because: Storing each comment in a document and adding the comment's key to an array property on the user profile wouldn't efficiently link comments to articles.
Answer is D in my opinion for "display user-submitted comments" and "unknown number of comments and articles"
I would go with C.
Answer is D
Firestore has a "hierarchical structure"
It is recommended to add the comment document IDs to an array property on the corresponding article document, rather than on a user profile. This approach allows you to easily retrieve all comments for a specific article by querying the comments collection using the article ID and then filtering the results based on the IDs in the article's comments array. Storing the comment IDs in the article document also avoids the need to make multiple read operations to retrieve the comments for a given article, which can be slow and increase latency. For example, you could create an array property named "comments" in the article document and add the comment document IDs to this array every time a user submits a new comment for the article. This allows you to efficiently retrieve all comments for a given article by querying the comments collection and filtering based on the IDs in the article's "comments" array.
https://firebase.google.com/docs/firestore/best-practices#high_read_write_and_delete_rates_to_a_narrow_document_range