Non, ce n'est pas mal du tout et en fait le ObjectId intégré est assez important dans l'index, donc si vous pensez que vous avez quelque chose de mieux, vous êtes plus que bienvenu pour changer la valeur par défaut du _id champ à n'importe quoi.
Mais, et c'est un gros mais , il y a quelques considérations à prendre en compte lors de la décision de s'éloigner de l'ObjectId formulé par défaut , en particulier lors de l'utilisation des _ids à incrémentation automatique, comme indiqué ici :https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field
Le multi-threading n'est pas un si gros problème car findAndModify et les serrures atomiques peuvent en fait s'en occuper, mais ensuite vous rencontrez votre premier problème. findAndModify n'est pas la fonction la plus rapide ni la plus légère et des baisses de performances importantes ont été constatées lors de son utilisation régulière.
Vous devez également tenir compte de la surcharge de le faire vous-même de toute façon, même sans findAndModify . Pour chaque insertion, vous aurez besoin d'une requête supplémentaire. Imaginez avoir un identifiant unique que vous devez interroger sur l'unicité de chaque fois que vous souhaitez insérer. Finalement, votre taux d'insertion chutera et votre temps de verrouillage augmentera.
Bien sûr le ObjectId est vraiment bon pour être unique sans avoir à vérifier ou à formuler sa propre unicité en touchant la base de données avant l'insertion, donc il n'a pas cette surcharge.
Si vous pensez toujours qu'un entier _id correspond à votre scénario, alors allez-y, mais gardez à l'esprit la surcharge décrite ci-dessus.
