If you have an existing ID (say from an existing dataset), then it is great for overriding _id with the one you have.
... keeo _id is untouched as it helps indexing etc.
MongoDB by default indexes the _id field. If you start nesting integers in the _id field, they will be indexed like everything else.
Thus, most RDBMs provide the identifier "auto-increment". This is good for small datasets, but really bad in terms of scalability. If you are trying to insert data on 20 servers at the same time, how do you save "auto-increment"?
The usual answer is that you are not doing this. Instead, you end up using the same GUIDs for these identifiers. In the case of MongoDB, an ObjectId is already specified.
I was interested to learn about some better strategy so that I could use the mongoId object as a more user-friendly and easy-to-remember key
Thus, the problem is that the identifier “easy to remember” is not actually associated with a “highly scalable database”. When you have a billion documents, identifiers are not really "easy to remember."
So you have to compromise here. If you have a table that can get really big, I suggest using ObjectId. If you have a table that is relatively small and not frequently updated (for example, the “lookup” table), you can create your own auto-increment.
The choice is really up to you.
source share