【问题标题】:Cloud Firestore user private documents in a shared collection共享集合中的 Cloud Firestore 用户私有文档
【发布时间】:2019-03-26 00:57:24
【问题描述】:

问题

我对 NoSQL 数据库设计相当陌生,我希望利用 Google 的 Cloud Firestore 来开发我正在创建的新应用程序。看起来简单而整洁。

在我的数据模型中,我有 userspages。一个用户可以拥有许多页面。用户可以将他们的帐户链接到其他用户(像家庭计划一样思考)。链接的用户将有一个领导用户,所有其他用户都是追随者。通过这种设计,所有关注者都可以访问领导者用户的页面。追随者可以以领导者的名义创建、读取、更新和删除页面。作为一个净效应,所有链接的用户共享页面。我认为结构应该是这样的。

/database/
    users/
        [user-doc]
    pages/
        [page-doc]

有助于塑造问题的约束

  • 我设想从大约 10 到 5 万用户开始,以后可能会突破 10 万。
  • 我设想每个用户平均拥有大约 30-40 个页面。
  • 我会将链接用户限制为最多 5 个用户。即一位领导者和四位追随者。

我想知道的事情......

我想确认的一件事是这个设计是一个很好的设计,特别是在 Cloud Firestore 的上下文中。

  1. 对于安全规则,当用户想要 R/U/D 一个 page 文档时,通过查看 user 是否拥有 pageuser是一个“追随者”类型的帐户,领导者是page 的所有者。这公平吗?

  2. 每个 page 文档的标识符将由 Firestore (as mentioned here) 自动生成。为了检索user(或链接的领导者)拥有的所有页面,是否像查询db.collection("pages").whereEqualTo.("page-owner", uid)一样简单?其中uid 是用户的唯一ID。如果有 100,000 个用户,每个用户有 40 个页面,那么这个查询会高效吗?

非常感谢您的意见!谢谢!

【问题讨论】:

    标签: firebase nosql google-cloud-firestore data-modeling


    【解决方案1】:
    1. 是的,查询随结果集的大小而不是集合的大小而缩放。

    【讨论】:

      猜你喜欢
      • 2018-03-22
      • 2021-03-27
      • 2021-05-09
      • 1970-01-01
      • 2021-08-12
      • 2019-07-23
      • 2019-11-16
      • 2018-11-19
      • 2018-03-17
      相关资源
      最近更新 更多