Cloud Firestore and data modeling: From RDBMS to No-SQL

Question

I am building an iOS app that is using Cloud Firestore (not Firebase realtime database) as a backend/database.

Google is trying to push new projects towards Cloud Firestore, and to be honest, developers with new projects should opt-in for Firestore (better querying, easier to scale, etc..).

My issue is the same that any relational database developer has when switching to a no-SQL database: data modeling

I have a very simple scenario, that I will first explain how I would configure it using MySQL:

I want to show a list of posts in a table view, and when the user clicks on one post to expand and show more details for that post (let say the user who wrote it). Sounds easy.

In a relational database world, I would create 2 tables: one named "posts" and one named "users". Inside the "posts" table I would have a foreign key indicating the user. Problem solved.

Poor Barry, never had the time to write a post :(

Using this approach, I can easily achieve what I described, and also, if a user updates his/her details, you will only have to change it in one place and you are done.

Lets now switch to Firestore. I like to think of RDBMS's table names as Firestore's collections and the content/structure of the table as the documents.

In my mind i have 2 possible solutions:

Solution 1:

Follow the same logic as the RDBMS: inside the posts collection, each document should have a key named "userId" and the value should be the documentId of that user. Then by fetching the posts you will know the user. Querying the database a second time will fetch all user related details.

Solution 2:

Data duplication: Each post should have a map (nested object) with a key named "user" and containing any user values you want. By doing this the user data will be attached to every post it writes.

Coming from the normalization realm of RDBMS this sounds scary, but a lot of no-SQL documents encourage duplication(?).

• Is this a valid approach?
• What happens when a user needs to update his/her email address? How easily you make sure that the email is updated in all places?

The only benefit I see in the second solution is that you can fetch both post and user data in one call.

Is there any other solution for this simple yet very common scenario?

ps: go easy on me, first time no-sql dev.

Thanks in advance.

Answer 1

Use solution 1. Guidance on nesting vs not nesting will depend on the N-to-M relationship of those entities (for example, is it 1 to many, many to many?).

If you believe you will never access an entity without accessing its 'parent', nesting may be appropriate. In firestore (or document-based noSQL databases), you should make the decision whether to nest that entity directly in the document vs in a subcollection based on the expect size of that nested entity. For example, messages in a chat should be a subcollection, as they may in total exceed the maximum document size.

Mongo, a leading noSQL db, provides some guides here Firestore also provided docs Hope this helps