How to Structure Your Data | Get to know Cloud Firestore #5

What people said

Recommends Kat · 2018-11 · Stack Overflow · on “Firestore: Running Complex Update Queries With Multiple Retrievals (ReactJS)”

You might want to back up a little and get a better understanding of the type of database that Firestore is. It's NoSQL, so things like rows and columns and tables don't exist. Try this video: [LINK] and this one: [this video] But yes, you could use a cloud function to update a value for you, or you could make the new Spent total calculation within your app logic and when you write the new value for Item 2, also write the new value for Spent total. But mostly, you need to understand how firestore stores your data and how it charges you to retrieve it. You are mostly charged for each read/write request, with much less concern for the actual amount of data you have stored overall. So it will probab

Recommends Jesse Lima · 2018-12 · Stack Overflow · on “How to create the following data structure in a NoSQL environment”

Firestore has a different approach to the NoSQL world. Once you know the data you will use (as You already do) there are some very important points about what architecture the data will have. And It depends a lot about how the data grows, what kind of queries you will need and how often you will use them. Some cases You can create a root collection that aggregates data and queries might be easier. There is a great video from Firebase Channel that might help. Check it out! How to Structure Your Data | Get to Know Cloud Firestore #5 [this video] [UPDATED] December 26th Others videos that might help to model and query your data is these videos: How to Connect Firebase Users to their Data - 3 Methods

Recommends Sculletbutt善 · 2019-02 · Stack Overflow · on “Is it possible to create a new Firestore database every time a new user is created in Firebase?”

In your case one firestore database will work perfectly. You will need to do some thinking on database structure This video will help [this video]

Recommends Frank van Puffelen · 2019-02 · Stack Overflow · on “Reduce reading documents in firebase firestore collection”

One option is to generate a document that contains all the information that you want to display on that order page. Probably this would be the ID and title of each book, but likely there's much more information that you store for a book, but don't show on the order page. Since all that data in this synthesized document goes onto a single page, it should fit well within the 1MB limit on the size of a document. This approach is quite common in NoSQL databases, where you often do additional work upon data changes, to make subsequent reads simpler/cheaper. Since reads are often much more common, this makes the reads much more scalable. For more examples of this see the video How to Structure You

Recommends Frank van Puffelen · 2019-03 · Stack Overflow · on “Going over read-quota in firebase firestore”

If you're trying to reduce the number of document reads, you'll need to reduce the number of documents that you need to read to implement your use-case. For example, it is fairly unlike that a user of your app will want to read the details of all 3000 items. So you might want to limit how many items you initially read, and load the additional items only on demand. Also consider if each item needs to be its own document, or whether you could combine all items of a user into a single document. For example, if you never query the individual items, there is no need to store them as separate documents. Another thing to consider if whether you can combine common items into a single document. An ex

Recommends Kato · 2019-06 · Stack Overflow · on “How can I segregate user data in firebase?”

Todd put together a great series on Firestore [LINK] and it covers database architecture in depth in eposides #3 [LINK] and #4 [this video] .

Recommends Kato · 2019-06 · Stack Overflow · on “Correct way to store an array of custom objects in Cloud Firestore?”

Todd put together a great series on Firestore [LINK] and it covers database architecture in depth in eposides #3 [LINK] and #4 [this video] .

Recommends matthew · 2020-03 · Stack Overflow · on “Advantages of firestore sub-collections”

To answer the original question about efficiency: Querying all people with the family 'Smith' from the people top-level collections really is not any slower than asking for all the people in the 'Smith' family sub-collection . This is explained in the How to Structure Your Data [this video] episode of the Get to Know Cloud Firestore video series. There are some trade-offs between top-level collections and sub-collections to be aware of. Depending on the specific queries you intend to use you may need to create composite indexes to query top-level collections or collection group indexes to query sub-collections. Both these index types count towards the 200 index exemptions limit [LINK] . These tra

Recommends Doug Stevenson · 2020-03 · Stack Overflow · on “Saving users scores and favorites in Firestore Database”

It sounds like you could use a general tutorial in nosql database design. I suggest watching this video series. [this video]

Recommends Rafael Lemos · 2020-03 · Stack Overflow · on “Suggested way to structure Firestore database for deeply nested set of spreadsheet like objects”

From my stand point, there is no obvious answer to your problem and indeed it does depend on what you want to optimize for. However there are a few points that you need to consider on your decision: Documents in Firestore have a limit of 1Mb/Document; Documents in Firestore have a limit of 20000 fields; Queries are shallow, so you don't get data from subcollections on the same query; For considerations 1 and 2, this means that if you choose the design you database to a big document containing everything, even though you said that your app will have lots of data, I doubt that it will be more than the limits mentioned, still, do consider those. Also, how necessary is it to get all the data at