我正在为本地群组开发管理应用程序。
该应用程序还显示每个组的联系人列表。
我想知道我应该如何设计我的数据库？
如果我将所有用户存储在根级集合中，则每次用户打开联系人列表时，它都会读取他所在组的所有用户文档。例如，假设有 1000 个联系人组，对于这样一个简单的任务，总共需要大量读取。
为组使用子集合也是如此。
将群组的联系人作为地图存储在群组文档中是不可扩展的。
使用组文档中的映射来索引非规范化模型中的集合或子集合也是如此。
这就是我卡住的地方。
我是否遗漏了什么，或者这些是我拥有的选项，我需要在每次用户打开联系人列表时进行大量阅读和为有限规模的群体设计的模型之间进行选择？
【问题讨论】：
标签： firebase google-cloud-firestore nosql datamodel
我认为这是一种常见的情况。许多项与较少的父项相关，我们希望显示父项的子项。
对于 Firestore，建议您限制查询。
例如，如果用户想查看群组的联系人列表，那很好，请进行查询。但不要一次显示所有 1000 多个联系人。甚至 Facebook 也不这样做（进入 Facebook 群组并点击“成员”，您只会看到十几个左右，并且当您向下滚动时，会进行更多查询以显示更多信息。）
用户期望这种行为：延迟加载或分页。
Firestore 限制/分页查询的文档：limit、paginate
这样，组可以是文档，而联系人可以是具有包含其所属组 ID 的 Array 字段的文档。要显示组的联系人，您可以对联系人集合使用“array-contains”查询。
类似的东西
contacts (collection)
|
--- {contactId} (document)
|
--- (...contact data...)
|
--- group_membership (array)
|
0--- 'groupId111'
|
1--- 'groupId222'
（对于contacts(col)/contact(doc)/group_membership(field) 我假设一个联系人可以属于多个组，如果不是这种情况，该字段可以是字符串而不是数组，但是如果您改变主意，将其设置为数组会更安全。）
我在这里要说的是，您对 db 结构的看法很好且很常见，您不必为了避免查询一千个联系文档而进行重组……因为您不必这样做。您不必查询最终用户实际需要的数据量的 100 倍。
【讨论】：