Suppose I have a collection savedGamesFull. Whenever a document is created in this collection, it receives the Firebase-generated ID; I then reuse this ID and give it to another document in a parallel collection savedGamesLight.

In another example, for each document in players collection, there would be a document with the same id in playerPublicProfiles and playerStats collections.

Basically, all this naming method does is that it saves a few lines of code here and there, and there is no need to keep the userId field in those parallel documents.

But after reading about hotspotting (although it doesn't seem to apply here) I got concerned that there may be issues with this naming.

So are there any downsides to having the same document IDs in several different collections?

CodePudding user response：

Is it OK to duplicate document IDs in different Firestore collections?

Yes. It is actually a quite common practice when it comes to identifying users across your application, no matter what the collection is.

I then reuse this id and give it to another document in a parallel collection savedGamesLight.

In the NoSQL world, it's always a good practice to denormalize data. This means that it totally makes sense to display data from lighter documents rather than from heavier documents.

But after reading about hot-spotting (although it doesn't seem to apply here) I got concerned that there may be issues with this naming.

Hot-spotting doesn't refer to having the same document IDs in multiple collections or sub-collections. It's about having sequential document IDs.

So are there any downsides to having the same document ids in several different collections?

Not at all. It's quite normal.

CodePudding user response：

You can use same document ID in multiple collection. Its pretty useful for one-one mapping e.g. using user's UID in users collection (stores private information) and profiles collection (stores public information).

Because you know ID of the document, you can fetch documents from all collections (players, playerPublicProfiles and playerStats) at once with Promise.all() and don't have to fetch player document, read public profile document ID and then fetch the profile.