带有子集合的云Firestore模式

Question

我正在从Firebase实时数据库切换到云Firestore。我的数据库包含拥有存储的用户，每个存储都包含盒子。每个用户都可以拥有多个包含盒子的存储器。每个存储可以包含几个盒子。每个箱子只能放在一个仓库里。

在我应用html" target="_blank">程序的主视图中，对于该特定用户，我需要列出所有存储以及每个存储中的框，如下所示：

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

然后，用户应该能够点击每个框以查看内容和更多信息。

在Firebase实时数据库中，每个用户只需一个请求，就可以获得该功能。现在有了Firestore，我不知道如何创建最好的模型，因为我只能进行浅层阅读。如果我使用子集合，我无法在一次请求中获得所有连接盒的存储。为了得到所有的盒子，我需要先做一个请求来得到所有的存储空间，然后每个存储空间做一个请求来得到盒子。

我对火系结构的想法如下，但我不确定这是不是可行的方法：

使用两个独立的集合

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"

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

在存储集合下使用两个单独的集合和一个字典。

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"

考虑到我上面解释的用户体验，这些结构中有哪一个是一个好的解决方案，还是我错过了一个更好的方法？

Answer 1

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

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

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

我认为这里需要注意的重要事项是存储文档的框_摘要条目。它只包含足够的信息，您可以在用户最初的“查看我的存储”屏幕上为他们提供所需的信息，而无需发出大量单独的请求，但它的缺点是，您需要做一些额外的工作来保持数据同步。这种折衷是否值得，取决于您认为用户添加或删除框的频率，以及他们查看“查看我的存储”屏幕的频率。