Firestore - good practice to use uid of FirebaseAuth as the document index for further relations

user_1648661 0
Viewed 196

i have a simple question regarding if it's a good practice to use the uid of the FirebaseAuth-Service for relations in other collections as the document index. So on login I get the uid of the FirebaseUser. With that I create an user like so:

create user

Now is that a good practice to use this uid as the index of another document somewhere in another collection like this:

sub_collection

Or is it more common to let the index be generated and add an uid field inside the document so that I can query it with 'uid' equal 'my_uid' for example?

I come from the SQL-side and I don't have that much experience about NoSQL and how to sturcture it well. It would be great if someone could give me an advice here.

google-cloud-firestore firebase-authentication firebase
1 Answers

This is not a problem at all to reuse the same document ID in different collections, whether this id is a user uid (from Auth) or any other value (including an auto generated Firestore id).

Or is it more common to let the index be generated and add an uid field inside the document so that I can query it with 'uid' equal 'my_uid' for example?

This is also a common approach, which can be interesting for example if you don't want to display the value of a Firestore document id (for example in an an url like https://www.whatever.com/players/-useruid- or https://www.whatever.com/players/-playername-).

Note however that this can generate some "tricky" side effects: for example if you want to avoid having two user profiles with the same user_name, in order to check that into a Transaction, you need to use the user_name as the id of the documents, since, with the Client SDKs it is not possible to execute a query within a Transaction (you need to define a DocumentReference to pass to the Transaction's get() method).

user_33718620
Related