我的应用程序的用户集合中的每个文档都有一个子集合。此子集合存储与用户相关的文档，但也可以将它们保存到主集合中，每个文档都有一个关联的 userId。
我选择了这种结构，因为它在当时似乎是最明显的，但我可以想象，如果我需要进行数据库维护，它会让事情变得更加困难。例如。如果我想清理这些文档，我必须先查询每个用户，然后再查询每个用户的文档，而如果我有一个主集合，我可以只查询所有文档。
这让我质疑子集合的意义何在，如果您可以将这些文档与 ID 相关联。它只是为了在您的文档接近 1MB 限制时可以扩展吗？
【问题讨论】：
标签： firebase google-cloud-firestore
编辑： 2021 年 10 月 29 日：
要清楚文档中存在的以下句子：
如果您不根据具有顺序值的字段进行查询。
时间戳只能不被认为是连续的。但是，它仍然可以被认为是连续的。相同的规则适用于按字母顺序排列的（Customer1、Customer2、Customer3、...）或几乎一切可以被视为可预测生成的值。
Firestore 索引中的此类顺序数据，最有可能写入存储介质上的物理邻近位置，因此存在这种限制。
话虽如此，请注意 Firestore 使用一种机制将文档映射到相应的位置。这意味着如果这些值不是随机分布的，则写入操作将不会正确分布在这些位置上。这就是存在这种限制的原因。
另请注意，您可以在特定时间内写入此类位置的数据量存在物理限制。可预测的键/值很可能最终会出现在同一个位置，这实际上很糟糕。所以有更多的变化来达到这个限制。
编辑： 2021 年 7 月 16 日：
由于这个答案听起来有点陈旧，我将尝试添加一些使用随着时间的推移而发现的子集合的优势：
暂时就这样，如果我发现其他好处，我会更新答案。
让我们举个例子。假设我们有一个用于测验应用程序的数据库模式，如下所示：
Firestore-root
|
--- questions (collections)
|
--- questionId (document)
|
--- questionId: "LongQuestionIdOne"
|
--- title: "Question Title"
|
--- tags (collections)
|
--- tagIdOne (document)
| |
| --- tagId: "yR8iLzdBdylFkSzg1k4K"
| |
| --- tagName: "History"
| |
| --- //Other tag properties
|
--- tagIdTwo (document)
|
--- tagId: "tUjKPoq2dylFkSzg9cFg"
|
--- tagName: "Geography"
|
--- //Other tag properties
其中tags 是questionId 对象中的子集合。现在让我们创建 tags 集合作为顶级集合，如下所示：
Firestore-root
|
--- questions (collections)
| |
| --- questionId (document)
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- title: "Question Title"
|
--- tags (collections)
|
--- tagIdOne (document)
| |
| --- tagId: "yR8iLzdBdylFkSzg1k4K"
| |
| --- tagName: "History"
| |
| --- questionId: "LongQuestionIdOne"
| |
| --- //Other tag properties
|
--- tagIdTwo (document)
|
--- tagId: "tUjKPoq2dylFkSzg9cFg"
|
--- tagName: "Geography"
|
--- questionId: "LongQuestionIdTwo"
|
--- //Other tag properties
这两种方法的区别在于：
tags，使用第一个模式非常容易，因为只需要CollectionReference（问题 -> questionId -> 标签）。要使用第二个模式实现相同的目的，而不是 CollectionReference，需要 Query，这意味着您需要查询整个 tags 集合以仅获取与单个问题对应的标签。
这种技术称为数据库扁平化，在 Firebase 中是一种非常常见的做法。因此，仅在需要时才使用此技术。因此，在您的情况下，如果您只需要显示单个问题的标签，请使用第一个模式。如果你想以某种方式显示所有问题的所有标签，建议使用第二种模式。
它是否只是为了在您的文档接近 1MB 限制时进行扩展？
如果您在文档中有对象的子集合，请注意子集合的大小不计入 1 MiB 限制。仅计算存储在文档属性中的数据。
2019 年 10 月 1 日编辑：
根据@ShahoodulHassan 的评论：
那么你没有办法使用第一个模式获取所有问题的所有标签吗？
其实现在有，我们可以使用Firestore collection group query获取所有问题的所有标签。需要注意的一点是，所有子集合必须具有相同的名称，例如 tags。
【讨论】：
So there is no way you can get all the tags of all the questions using the first schema. 对名为“tags”的集合的集合组查询现在不能解决这个问题吗？
我发现子集合的最大优势是它们有自己的写入速率限制，因为每个子集合都有自己的索引（假设您没有 集合组 em> 索引）。这对于小型应用程序可能不是问题，但对于中/大型应用程序来说可能非常重要。
想象一个聊天应用程序，其中每个聊天都有一系列消息。您需要按时间戳索引消息以按时间顺序显示它们。 Firestore 对顺序值 is 500/second 的写入限制，这绝对是中型应用程序所能达到的（特别是如果您考虑到流氓用户编写消息的可能性——目前使用安全规则不容易防止）
// root collection
/messages {
chatId: string
timeSent: timestamp // the entire app would be limited to 500/second
}
// sub-collection
/chat/{chatId}/messages {
timeSent: timestamp // each chat could safely write up to 500/second
}
【讨论】：
很惊讶这之前没有被提及，但是子集合可以（在某些情况下）帮助绕过 orderBy 限制：
您不能按包含在等式 (==) 或 in 子句中的字段对查询进行排序。
假设您想获取 用户最近 10 次登录：
顶级：
//We can't use .orderBy after .where('==')
USER_LOGINS.where('userId', '==', {uid}).limit(10)
子集合：
//With a subcollection we can order and limit properly
USERS.doc({uid}).collection('LOGINS').orderBy('unixCreated', 'desc').limit(10);
【讨论】：