如何在内部加入分页列表视图的 firestore 集合

How can I inner join firestore collections for a paginated listview

我们可以轻松地使用 Firestore 集合对 Recyclerview 进行分页。但就我而言,我有三个依赖集合。他们是

 1. product (10000000 entries expected) 
 2. category (100000 entries expected) 
 3. region (50000 entries expected)

在 Recyclerview 中,我必须显示产品、类别和区域的详细信息,如下图所示。正如我们所知,没有像 SQL 这样的内连接查询选项。我在每个产品对象中都存储了类别 ID 和区域 ID。获取产品列表后,我必须根据每个产品对象中的类别和区域 ID 填写类别名称和区域名称。构建该产品列表后,我必须将其传递给 Recyclerview 适配器。如何使用 Firestore 实现这些复杂的架构以满足正常的 SQL 功能?就我而言,Firestore 已得到确认。还有就是分页。

我尝试在初始化页面时获取不同变量中的所有类别和区域。在分页时,我必须根据它们的 ID 找到并放置所需的类别名称和区域名称。但是我们需要保留包含大量数据的类别和区域列表变量,直到 activity 结束,这不是一个好的做法。我需要克服这个。仅供参考:我正在使用 Kotlin

请查看以下每个文档对象的基本结构示例。

产品

{
    "productId": 122,
    "productName": "product name 1",
    //other product details here
    "categoryId": 758,
    "regionId": 395
}

类别

{
    "categoryId": 90474,
    "categoryName": "category name 200",
    //other category configuration details here
}

地区

{
    "regionId": 2372,
    "regionName": "tokyo",
    //other region details here
}

实际场景

  1. 如果我需要给特定品类一个特定百分比的折扣,那么我们需要在每行产品中单独计算。

  2. 如果我需要根据不同的地区显示不同的运费,那么也是同样的问题。

这意味着每次我向类别和地区添加特定详细信息时,我都必须使用更新后的地区和类别详细信息更新列表中的所有产品。

#1 答案:不要试图将 NoSQL 视为 SQL.

SQL DRY 原则专门将数据保存在一个 table 中,并使用记录 ID 在 table 之间交叉引用。

NoSQL 功能允许惊人的规模和速度,但您必须将其用作 NoSQL。更具体地说,“DRY”变成了“DO Repeat Yourself”,尤其是因为记录几乎是无限大的。如果“加入”数据完全接近于静态,最好将其复制到引用记录。

而不是使用记录 ID 在 table 之间进行交叉引用,而是使用那些 table(例如您的示例“类别”)作为真实来源(即数据必须来自它们) 并将信息复制到引用记录。在您的示例中,您有:

{
    "categoryId": 90474,
    "categoryName": "category name 200",
    //other category configuration details here
}

那么您的产品信息就变成了:

{
    "productId": 122,
    "productName": "product name 1",
    //other product details here
    "category": {
      "categoryId": 758,
      "categoryName": "category name 200"
      //other category configuration details here
    },
    "region": {
      "regionId": 2372,
      "regionName": "tokyo",
      //other region details here
    }
}

因此,当您检索产品记录时,所有“加入”信息都存在。包含 Id 的原因(记住 document/record 非常大)是因为它需要更新的次数不频繁(记住上面:大部分是静态的),您可以查询使用它的记录,并更新它们。这可能是一个几乎消失的罕见事件。