具有子集合的Cloud Firestore架构

Question

我正在从Firebase实时数据库切换到Cloud Firestore.我的数据库包含拥有存储的用户,每个存储包含Box.每个用户可以拥有多个包含Box的存储.每个存储可以包含多个Box.每个Box只能在一个存储中.

在我的应用程序的主视图中,对于该特定用户,我需要列出每个存储中包含Box的所有存储,如下所示:

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

然后,用户应该能够进入每个Box以查看内容和更多信息.

在Firebase实时数据库中,每个用户可以获得一个请求.现在有了Firestore,我不知道如何创建最好的模型,因为我只能进行浅读.如果我使用子集合,我无法在一个请求中将所有连接的Box存储到它.然后获取所有Box,我需要首先执行一个请求以获取所有存储,然后为每个存储获取一个Box.

我对Firestore中的结构的想法将是以下之一,但我不确定它是要走的路:

结构1:

使用两个单独的集合

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"

此解决方案的问题是在为特定用户加载Boxes集合时如何获取存储的名称.然后我还需要在本地每个存储下对它们进行排序.

我对结构的另一个想法是:

在Storage Collection下使用两个单独的集合和一个字典.

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"

考虑到我上面解释过的UX,这些结构中的任何一个都是一个很好的解决方案,还是有一种我错过的更好的方法？

Answer 1

以下是我可能会如何构建您的数据。

请注意，我将Storage作为子集合放在您的Users集合下，但这完全是可选的。如果每一位存储只能由一个用户拥有，那么将其保留为子集合可能会很好，如下所示。但是，如果一个存储项目可以由多个用户拥有或经常切换用户，那么您最好将其设为顶级集合。

 + 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"

我认为这里需要注意的重要事项是文档box_summary的输入storage。这包含足够的信息，您可以在用户最初的“查看我的存储”屏幕上为他们提供所需的信息，而无需发出一堆单独的请求，但它的缺点是您需要做一些额外的事情努力保持数据同步。这种权衡对您来说是否值得取决于您认为用户添加或删除框的频率，以及他们查看此“查看我的存储”屏幕的频率。