Cloud Firestore diagram with additional collections

I am moving from the Firebase Realtime database to Cloud Firestore. My database contains users who own the repository, each repository contains mailboxes. Each user can own several repositories containing mailboxes. Each vault can contain multiple mailboxes. Each box can be in only one storage.

In the main view of my application for this particular user, I will need to list all the storages with boxes in each repository, for example:

Storage 1: Box 1 Box 2 Storage 2: Box 3 Box 4 Box 5 ... 

Then the user can connect to each box to see the contents and additional information.

In the Firebase Realtime database, you could get one request for each user. Now with Firestore, I'm not sure how to create a better model, since I can only do small readings. I cannot get Storages with all related mailboxes in the same request if I use subcategories. To then get all the boxes, I first need to make one request to get all the Vaults, and then one for each Vault to get the Boxes.

My idea for a structure in Firestore would be one of the following, but I'm not sure if this is the way to go:

Structure 1:

Using two separate collections

 Storages Collection storage_1: name: "Storage number one" user_id: "1" storage_2: name: "Storage number two" user_id: "1" Boxes Collection box_1: storage_id: "1" user_id: "1" box_2: storage_id: "1" user_id: "1" 

The problem with this solution is how to get the repository name when loading the Boxes collection for a specific user. Then I will also need to sort them under each repository locally.

My other idea for the structure:

Using two separate collections and a dictionary in a collection of repositories.

 Storages Collection storage_1: name: "Storage number one" user_id: "1" boxes: [{ box_id: "1", name: "Box number 1" }, { box_id: "2", name: "Box number 2" }] storage_2: name: "Storage number two" user_id: "1" boxes: [] Boxes Collection box_1: storage_id: "1" user_id: "1" box_2: storage_id: "1" user_id: "1" 

Is any of these structures a good solution, given my UX explained above, or is there a better way that I skipped?

+5
source share
1 answer

Here is how I can structure your data.

Note that I put Storage as a subset in your Users collection, but this is completely optional. If each bit of storage can belong to only one user, it would be nice to save it as a subcollection, as shown below. But if a single storage item can belong to several users or changes users frequently, you are probably better off making it a top-level collection.

  + Users (collection) * user_a (document) - name: "Joe" - last_login: 20171130 + Storage (subcollection) * storage_1 (document) - name: "Living Room Storage" - box_summary: {box_1: "Fancy box", box_2: "Plain box"} + Boxes (subcollection) * box_1 (document) - name: "Fancy box" - contents: "Gold coins and jewels" * box_2 (document) - name: "Plain box" - contents: "Books" 

I think the important point here is to write the box_summary Storage document. It contains enough information that you can provide users with what they need on their initial “View my vault” screen without having to create a bunch of separate requests, but this is due to a drawback that you will need to do a little work to synchronize the data. Regardless of whether this compromise is worth your while, it depends on how often you think your users will add or remove mailboxes, and how often they will view this “View my vault” screen.

+4
source

Source: https://habr.com/ru/post/1273470/


All Articles