3 回答

TA貢獻1966條經(jīng)驗 獲得超4個贊
您在這里擁有的是一個地圖字段,通常應該自動為其創(chuàng)建索引。
這確實意味著您將擁有與產(chǎn)品一樣多的索引,這意味著:
您可以擁有的產(chǎn)品數(shù)量受到限制,因為每個文檔最多有 40,000 個索引條目。
您為每個文檔支付更多費用,因為您為每個索引的存儲付費。
如果這些不是您想要的,您將不得不切換回您的原始模型,并使用您在那里的查詢限制。似乎沒有適合您的兩個要求的解決方案。

TA貢獻1843條經(jīng)驗 獲得超7個贊
在我們聊天討論之后,這是我建議的起點。誰知道最終架構(gòu)會是什么樣子,但我認為這個或非常接近這個。您說一個用戶可以同時存在于多個倉庫中,并且多個倉庫可以同時包含相同的產(chǎn)品。您還說過,一個倉庫在給定時間永遠不能擁有超過 40 個用戶,因此 40 個用戶的數(shù)組肯定不會侵犯 Firestore 的文檔1,048,576字節(jié)限制。
[collection]
<documentId>
- field: value
[depots]
<UUID>
- depotId: string "depot456"
- productCount: num 5,000
<UUID>
- depotId: string "depot789"
- productCount: num 4,500
[products]
<UUID>
- productId: string "lotion123"
- depotId: string "depot456"
- users: [string] ["user10", "user27", "user33"]
<UUID>
- productId: string "lotion123"
- depotId: string "depot789"
- users: [string] ["user10", "user17", "user50"]
[users]
<userId>
- depots: [string] ["depot456", "depot999"]
<userId>
- depots: [string] ["depot333", "depot999"]
在 NoSQL 中,存儲很便宜,并且計算不會像使查詢成為可能和高效(快速且便宜)所需的那樣對數(shù)據(jù)進行非規(guī)范化。
要在單個查詢中查找所有 depot,其中user10和lotion123都為真,請查詢產(chǎn)品集合 where productIdequalsx和usersarray-containsy并從這些結(jié)果中收集depotId值。如果您想為其他內(nèi)容保留數(shù)組包含操作,則必須進一步對數(shù)據(jù)進行非規(guī)范化(替換單個用戶的數(shù)組)?;蛘撸梢詫⒋瞬樵儾鸱譃閮蓚€單獨的查詢。
使用此模型,當用戶離開倉庫時,獲取users數(shù)組包含該用戶的所有產(chǎn)品并將其userId從數(shù)組中刪除。當用戶加入倉庫時,獲取所有depotId等于的產(chǎn)品x并將其附加userId到數(shù)組中。
觀看此視頻以及 Rick 的其他視頻,以深入了解 NoSQL:https ://www.youtube.com/watch?v=HaEPXoXVf2k

TA貢獻1846條經(jīng)驗 獲得超7個贊
如果您不確定用戶和產(chǎn)品的數(shù)量,那么您的數(shù)據(jù)庫結(jié)構(gòu)似乎不適合這種情況,因為 firestore 文檔存在大小和長度限制。您應該為產(chǎn)品和用戶創(chuàng)建單獨的集合,即規(guī)范化您的數(shù)據(jù)并在產(chǎn)品集合中為用戶提供參考。
User :
{
userId: documentId,
name: John,
...otherInfo
}
Product :
{
productId: documentId,
createdBy: userId,
createdOn:date,
productName:"exa",
...otherInfo
}
這樣,文檔的大小將受到限制,即如果您不確定大小,請嘗試避免在 firestore 中使用地圖/數(shù)組。此外,在這種情況下,查詢的數(shù)量會增加,但在這種情況下您不需要很多索引。
添加回答
舉報