I have a Firestore collection called users that stores all my user info. When registering a new user, I first register them with Firebase Auth, then create the record in the users collection. Right now I'm storing the uid as a field, which means when I want to query a user's info, I need to do a query with a WHERE clause. However, one alternative to faster querying would be to store the uid as the document ID for the collection. That would make it so that I could query the collection with a specific ID, which intuitively seems faster.

Using the uid as the doc ID makes me worried about some stuff:

1. I'm not sure if I can assume that uniqueness for the uid in Firebase Auth implies uniqueness when using it as the doc ID in a Firestore collection.
2. I watched a tutorial video by Todd that said that querying is faster if you use the auto-generated document ID that Firestore provides. Given this, I wouldn't want to take a risk using something else when the provided doc ID is known to be faster for querying.

What would be the better approach to make querying as efficient as possible, assuming you are querying only based on uid? Or is the difference so negligible that this is a moot point?

CodePudding user response：

yes, that is the most recommended approach because firebase auth ensures that your users have a unique id so no need to worry about duplicates. Another thing is storing separate id other than the uid is redundant because what you'll need most of the time in your app is the user uid to make sure that the auth user and the stored user are one and only the same person.

CodePudding user response：

If the uid in Firebase Auth is unique, and you're building the users collection based on the uid from Firebase Auth, then it follows that the uids which will populate the users collection will also be unique.

The only way this wouldn't be the case is if you're going to be mixing manually generated entries into the users collection with your own uids that aren't following Firebase Auth's generation procedures.

I did a mini project like this earlier this year that pretty much did exactly this (users sign-in with google, uid gets added to the users collection, and then their data gets stored under their uid in the collection). It wasn't a commercial product and my userbase was fairly small, but I didn't observe any reason for concern at the time.

Re: speed, I'm not sure what the impact is, but I would expect it to be negligible enough to call it moot. Querying a collection is basically just searching a list/array for a value, and most backends tend to handle a basic operation like that pretty efficiently.

CodePudding user response：

CollectionReference users = FirebaseFirestore.instance.collection('users');

Future<void> addUser() {
  return users
    .doc(current_uid)
    .set({
      'full_name': "Mary Jane",
      'age': 18
    })
    .then((value) => print("User Added"))
    .catchError((error) => print("Failed to add user: $error"));
}

You can then retrieve you data directly by using the uid which is most efficient approach.

Something like...

CollectionReference users = FirebaseFirestore.instance.collection('users');

users.doc(auth_ui).get(). // Future