相关疑难解决方法(0)

我在我的 Android 应用程序中使用 Cloud Firestore 数据库，并且我在集合中有不同的文档，例如：用户 uid、餐厅的按键和我的食谱的数字。

我的数据库：

users
  uid1
  uid2
  ...
resturants
  pushedId1
  pushedId2
  ...
recipes
  0001
  0002
  ...

对于我了解使用 uid 的用户，但最好为我的餐厅使用 Firestore 推送的 id？这是约定还是为什么要使用它？

我还尝试使用UUID 类生成唯一键但对我来说只使用数字作为我的食谱更容易。这是一个糟糕的方法吗？

任何帮助将不胜感激，谢谢！

我在Firebase Firestore 文档的“最佳实践”中看到，您应该：

避免按字典顺序关闭文档的高读取或写入率，否则您的应用程序将遇到争用错误。

给出的如何不写入文档 ID 的示例是：

客户 1、客户 2、客户 3、...

我正在将数据从外部服务映射到 Firestore 集合，并且我想保留它们的原始 ID 名称。它们以 为前缀entry_，但以随机/唯一字符串作为后缀，如下所示：

entry_{Unique_String}, entry_{Unique_String}, ... entry_{Unique_String}

每个文档 ID 是否以 为前缀entry_，但后跟一个随机字符串，将文档分类为按字典顺序接近并因此容易成为热点的文档？

或者，只有当它们确实被命名时才会被归类为：

entry_1, entry_2, entry_3, entry_4 ... <and so on>

我当然可以entry_在读取/写入时删除/添加 ID，但这会增加服务器/客户端的复杂性。*

*根据 Alex Mamo 的评论进行编辑以澄清：

由于以下示例，复杂性会增加：

• "entry_"在原始数据集上下文中读取/写入文档或需要发送回外部服务的任何地方，引入剥离/前置功能。
• 可能需要创建文档字段来跟踪（例如type = "entry"）在同一个集合中使用多个类别的文档 ID 的情况——根据用例，这可能不是一个缺点，例如，如果执行类型比较。
• 对于源自相同外部服务且具有相同前缀唯一字符串的其他类别类型（例如foo_， ）重新实现上述内容非常繁琐。bar_