firebasegoogle-cloud-platformgoogle-cloud-firestorefirebase-authenticationdata-modeling

the right way to model the data in collection and documents

I am building an app where I am planning to use the Firestore database. the structure needs to be like this:

users (collection) --> uids (documents one per user uid)

now each user uid document will store two types of information

  1. profile of the user such as name, age, etc
  2. financial data where each node with have one day of data.

for financial data, it makes sense to me to have a financial node under UIDs of type collection with each day a document like below

uid --> financial (collection) --> <date> (where each date is a document)

however, I am not sure what should be the profile node. Should it be a collection or just a map object? I am open to suggestions if this should be modeled differently for the better.

Solution

  • Adding your users into a "users" collection in Firestore, it's quite a common practice.

    Now each user UID document will store two types of information.

    1. Profile of the user such as name, age, etc.
    2. Financial data where each node with have one day of data.

    It's normal to store the name, age, etc in the user document. However, when it comes to financial data, there is something that you should take into consideration. You're limited to how much data you can put into a document. According to the official documentation regarding usage and limits:

    Maximum size for a document: 1 MiB (1,048,576 bytes)

    As you can see, you are limited to 1 MiB total of data in a single document. When we are talking about storing text, you can store pretty much but if you intend to store complex (financial) objects, then should be careful about this limitation.

    For financial data it makes sense to me to have a financial node under UIDs of type collection with each day a document.

    Yes, for financial data, it makes more sense to have a collection of documents. And since the financial data is related to each user, it makes even more sense to add the data under a sub-collection in the user document.

    I am not sure what should be the profile node. Should it be a collection or just a map object?

    If the data that corresponds to a user can fit into the maximum 1 MiB, then you should definitely store the user data, either as separate fields inside the document or as a Map, as you already mentioned.