firebase - 具有子集合的 Cloud Firestore 架构

Question

我将从 Firebase Realtime 数据库切换到 Cloud Firestore。我的数据库包含拥有存储的用户，每个存储都包含盒子。每个用户可以拥有多个包含盒子的存储。每个存储可以包含多个盒子。每个盒子只能位于一个存储中。

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

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

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

在 Firebase 实时数据库中，每个用户只需一个请求即可实现这一目标。现在使用 Firestore，我不确定如何创建最佳模型，因为我只能进行浅读。如果我使用子集合，我无法在一个请求中获取包含所有连接的盒子的存储。要获取所有盒子，我需要首先执行一个请求来获取所有存储，然后为每个存储发出一个请求来获取盒子。

我对 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 集合时如何获取存储的名称。然后我还需要在本地每个存储下对它们进行排序。

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

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

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 作为子集合放置在您的 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"

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