为文件名提供UID [英] Giving the UID for the document's name

查看:37
本文介绍了为文件名提供UID的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想知道什么是在Firestore数据库中保存用户首选项的最佳实践.我会尝试用一个例子来解释...

I would like to know what is the best practice to save users preferences in my firestore database. I would try to explain with an example...

我的用户"集合中有这种文档(名称由Firebase随机生成),其中包含3个字段:

I have this kind of Document in my "users" Collection (the name is random generated by Firebase) with 3 fields :

  • user_uid :字符串
  • 昵称:字符串
  • android_lover :布尔值
  • user_uid : String
  • nickname : String
  • android_lover : boolean

在我的Android项目中,当我想搜索用户"DFDDE45554SDC"的文档时,我在哪里搜索了user_uid ="DFDDE45554SDC".

In my Android project, when I want to search the Document of the user "DFDDE45554SDC", I search where user_uid = "DFDDE45554SDC".

我的用户"集合中有这种类型的文档(名称是使用用户的UID创建的),其中包含2个字段:

I have this kind of Document in my "users" Collection (the name is created with the UID of the user) with 2 fields :

  • 昵称:字符串
  • android_lover :布尔值
  • nickname : String
  • android_lover : boolean

在我的Android项目中,当我要搜索用户"DFDDE45554SDC"的文档时,我只搜索了文档"DFDDE45554SDC".

In my Android project, when I want to search the Document of the user "DFDDE45554SDC", I just search the Document "DFDDE45554SDC".

我指定:我不希望重复的用户.那么,最佳实践是什么(安全,优化等)?为什么?

I specify : I don't want duplicate users. So, what is the best practice (security, optimisation,...) ? Why ?

推荐答案

出于某些原因,我建议 Case 2 更有效:

I would suggest that Case 2 is more effective, for a few reasons:

  • 我们已经知道用户的ID,因此无需在此处使用其他ID.
  • 使用 usersCollection.document(userId)易于构建,并且是直接的 DocumentReference 而不是 Query ,因此:
    • DocumentReference 可以存储在Firestore数据库中,而 Query 则不能.
    • DocumentReference 的扩展可能比指示Firestore数据库使用 whereEqualTo("user_uid",userId)执行过滤器查询更好(尽管使用索引,但性能差异很大)在这一点上可以忽略不计.)
    • Query 将始终返回结果的集合(即使只有1个),而不是确切的文档.
    • We already know the user's ID, so don't need to use a different ID here.
    • Using usersCollection.document(userId) is simple to construct and is a direct DocumentReference, rather than a Query, therefore:
      • A DocumentReference can be stored in the Firestore database, whereas a Query cannot.
      • A DocumentReference would likely scale better than instructing the Firestore database to perform a filter query using whereEqualTo("user_uid", userId) (although with indexing, the performance difference is likely negligible at this point).
      • A Query will always return a collection of results (even if there is only 1), rather than the exact document.

      我想到使用 Case 1 的唯一真正动机是将您的文档命名方案与数据库中的其他集合标准化,但这与Firestore无关紧要.

      The only real incentive I can think of to use Case 1 would be to standardise your document naming scheme with other collections in your database, but this doesn't really matter so much with Firestore.

      有关Android中两者的简要示例:

      For a quick example of the two in Android:

      案例1

      db.collection("users")
          .whereEqualTo("user_uid", "DFDDE45554SDC")
          .limit(1)
          .get().addOnCompleteListener(new OnCompleteListener<QuerySnapshot>() {
              @Override
              public void onComplete(@NonNull Task<QuerySnapshot> task) {
                  if (task.isSuccessful()) {
                      for (DocumentSnapshot document : task.getResult()) {
                          // Even with limit(1), we still receive a collection
                          // so iterate this to obtain the desired document
                      }
                  }
              }
          });
      

      案例2

      db.collection("users")
          .document("DFDDE45554SDC")
          .get().addOnCompleteListener(new OnCompleteListener<DocumentSnapshot>() {
              @Override
              public void onComplete(@NonNull Task<DocumentSnapshot> task) {
                  if (task.isSuccessful() && task.getResult() != null) {
                      // We have access to the single desired document directly
                      DocumentSnapshot document = task.getResult();
                  }
              }
          });
      

      这篇关于为文件名提供UID的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆