我有两个关于firestore collection group的问题。
我的数据结构就像下面不同的商店(多供应商应用程序)不同的购物车。
Users>userId1>Carts>storeId1>Items>productId1
>storeId2>Items>productId1
>productId2
Users>userId2>Carts>storeId1>Items>productId1
现在，每当所有者更改产品价格时，我要更新包含该产品的所有用户的购物车。如果我将Items子集合设置为集合组，是否会出现性能问题?我的意思是更深的收集组会影响性能吗?或者不管嵌套子集合有多深，性能只取决于文档的数量。
第二个问题是相同的documentId(productId1)将在多个Items子集合中。因此，当它合并并通过索引作为一个巨大的Items集合时，相同的文档id会有任何冲突吗?
制作一个嵌套subcollection性能应该没有区别。每个集合和子集合，无论深度如何，都应该相互独立完整地运行。集合仅由其路径标识，该路径是一个字符串。
Firestore的主要性能特征是查询随着结果集的大小而扩展，而不是集合的大小。所以，你可以有大量的大集合，但这不会影响查询的性能。显然，在集合的路径中添加一些额外的组件根本不会影响性能。
对于您的第二个问题，文档ID是唯一的，如果您的主要文档ID(如userID)没有相同的ID，则不会有冲突，Firestore将不允许相同的文档ID在同一集合内，以便在索引您的组集合时不会有冲突。
。
Users > userId1 > Carts > storeId1 > Items > productId1
Users > userId2 > Carts > storeId1 > Items > productId1
从上面的示例中，索引两个具有相同子集合路径但使用不同主文档(userID)的文档将导致不同的索引，并且不会导致任何冲突。