我有數(shù)百個項目的子集合，這些項目可以由其所有者手動排序。
我想知道在Firebase中處理大塊排序數(shù)據(jù)的最佳方法是什么。
現(xiàn)在我正在使用一個帶有大整數(shù)值的“order”字段。當(dāng)創(chuàng)建一個新項目時，我會按照上一個項目的順序，向其添加1000 000，然后將其設(shè)置為新項目。但是如果一個項目在兩個項目之間移動，我需要更新它的順序。所以我取這兩個項目之間的差值，除以2，然后設(shè)置新的順序。
事情是這樣的
限制是，如果我繼續(xù)在兩個其他項目之間添加項目，那么差異將接近1（500/2=250，250/2=125。。。62... 31... 15... 7.3...). 在這一點上，我將無法再對這兩個項目之間的任何內(nèi)容進行排序。
所以我的第一個想法是，一旦我接近1，批量更新以下所有項目。這是可行的，但我不喜歡這個解決方案。
所以我想知道，如果我創(chuàng)建一個數(shù)組字段（在一個孤獨的子文檔中）列出所有項目ID，然后使用它列出項目，會怎么樣。陣列非常適合這樣做，所以很誘人。
盡管如此，我知道Firestore文檔的大小不能超過1Mb，所以我想知道我獲得這樣大小的文檔的可能性有多大。
我還想知道這個主意有多糟糕。這很少見，但有些收藏品可能有5000件左右（有時可能會更多）。
謝謝你的幫助
使用數(shù)組是維持訂單最常用的方法。它的主要問題實際上是最大文檔大小，以及需要讀取整個數(shù)組才能添加/更改其中的項。
將項目放置到的兩個項目之間的差異細分的方法也很常見。我只是使用了一個浮點數(shù)，在我看來，它讀起來更自然一些，并且去掉了最小距離1。但在執(zhí)行計算的平臺上或Firestore的后端，當(dāng)您接近浮點數(shù)的最大精度時，您可以進行的交換數(shù)量仍然有限制。
這些選項之間沒有單一的最佳選擇，這完全取決于您的use-case、您訪問數(shù)據(jù)庫的方式以及您希望執(zhí)行操作的次數(shù)。我通常在數(shù)量較少時使用陣列，如果我可以在服務(wù)器上執(zhí)行操作（帶寬不是問題），甚至可以使用中等大小的陣列。對于較大的系統(tǒng)，我使用浮點
ranking字段，并且傾向于忽略該字段的最大精度。如果被迫的話，我可能會想出一種優(yōu)雅的方法來定期重置ranking值。