Firebase Firestore - relational data design approa

Question

I'm totally new to Firebase, and I'm trying to get my head round the best db model design for 'relational' data, both 1-1 and 1-many.

We are using the Firestore db (not the realtime db).

Say we have Projects which can contain many Users, and a User can be in multiple Projects

The UI needs to show a list of Users in a Project which shows things like email, firstname, lastname and department.

What is the best way to store the relationship?

• An array of User ids in the Project document?
• A map of Ids in the Project document?

Ive read the above approaches were recommended, but was that for realtime database? Firestore supports Sub Collections, which sound more appropriate...

• A sub collection of Users in the Project document?
• A separate collection mapping Project id to User id?
• A Reference data type? I've read here https://firebase.google.com/docs/firestore/manage-data/data-types about Reference data type, which sounds like what I want, but I cant find any more on it!

If its just a map or array of Ids, how would you then retrieve the remaining data about the user? Would this have to sit in the application UI?

If its a sub collection of Users documents, is there any way to maintain data integrity? If a user changed their name, would the UI / a cloudFunction then have to update every entry of that users name in the Sub collections?

any help / pointers appreciated...

Answer 1

The approach for modeling many-to-many relationships in Firestore is pretty much the same as it was in Firebase's Realtime Database, which I've answered here: Many to Many relationship in Firebase. The only difference is indeed that you can store the lookup list in a sub-collection of each project/user.

Looking up the linked item is also the same as before, it indeed requires loading them individually from the client. Such a client-side join is not nearly as slow as you may initially expect, so test it before assuming it can't possibly be fast enough.

Ensuring data integrity can be accomplished by performing batched writes or using transactions. These either completely succeed or completely fail.