Reputation: 2296
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:
Now is that a good practice to use this uid as the index of another document somewhere in another collection like this:
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.
Upvotes: 2
Views: 340
Reputation: 83068
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).
Upvotes: 1