No, no está nada mal y, de hecho, el ObjectId incorporado es bastante considerable dentro del índice, por lo que si cree que tiene algo mejor, puede cambiar el valor predeterminado de _id campo a lo que sea.
Pero, y esto es un gran pero , hay algunas consideraciones al decidir alejarse del ObjectId formulado por defecto , especialmente cuando se usan los _id de incremento automático como se muestra aquí:https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field
Los subprocesos múltiples no son un problema tan grande porque findAndModify y las cerraduras atómicas en realidad pueden encargarse de eso, pero luego te encuentras con tu primer problema. findAndModify no es la función más rápida ni la más liviana y se han notado caídas significativas en el rendimiento al usarla regularmente.
También debe considerar la sobrecarga de hacer esto usted mismo de todos modos, incluso sin findAndModify . Para cada inserción necesitará una consulta adicional. Imagine tener una identificación única que debe consultar la unicidad de cada vez que desea insertar. Eventualmente, su tasa de inserción se reducirá y su tiempo de bloqueo aumentará.
Por supuesto, el ObjectId es realmente bueno para ser único sin tener que verificar o formular su propia singularidad tocando la base de datos antes de la inserción, por lo tanto, no tiene esta sobrecarga.
Si todavía cree que un _id entero se adapta a su escenario, hágalo, pero tenga en cuenta la sobrecarga descrita anteriormente.
