Problem with referenced documents after re-creating collection documents

Using a “songs” collection, and a generic “translations” collection, which can contain translations of documents from other collections.

If I need to recreate some of the “songs” documents (as I am retrieving them from an external api), then the Object_id would change.

In all documentation I see that by design, it’s better to use the Object_id of the document as a reference, but it is volatile. (I have also read that Sharding might change the Object_id).

Why is not a best practice to have our own internal unique ID?
After recreating the songs, I will lose the reference to their translations.

Song Document example:

_id: Object_id,
lang: "english"
title: "song title",
artistid: "artistid",
songURL: "songURL",

Translation Document example:

_id: Object_id,
refid: Object_id,
ref: "songs",
lang: "spanish",
title: "titulo de la cancion",

Hi @Mnt_Bl,
I will try to answer to some of your questione:

I raccomend you to read:

It’s normal because the 4 byte of timestamp will change surely when you create a new documento song

Hoping Is It useful for you!


thanks @Fabio_Ramohitaj,

My question is more about the need of creating and maintaining a different unique id to identify documents.

I think there has to be some considerations when best practices are defined, such as:

  • Are the documents internally generated, or can some of them be generated externally?
  • Would the documents be shared with external resources?
  • Do the documents need to be referenced? And what is the impact of losing reference id?

Another case can be when dealing with countries ISO 3166. Parts of a country document can change (an alpha id, a country code, or even the country name). But a change can have a major impact to the application.

In this case, I am also thinking to create my own internal id, so in case a country document changes, I can easily update the document and the impact to the overall application would be low.

But I am quite new in MongoDB, and not sure if this approach is correct, and other smart & experienced people have a well-founded solution.