Quelques-uns que j'ai vu :
- Ce n'est pas génial pour les URL. Twitter me donne une URL du type http://twitter.com/gatesvp , avec un ObjectId vous obtenez une URL comme http://example.com/ab12ab12ab12ab12ab12ab12 .
- L'ObjectId se fragmente très mal. Ce n'est pas vraiment aléatoire, c'est quelque peu séquentiel, donc les nouveaux utilisateurs se regrouperont sur des fragments plutôt que de les distribuer au hasard.
- Vous avez souvent besoin d'un autre identifiant unique. La plupart des sites Web exigent un e-mail unique ou un nom d'utilisateur unique. Oui, vous pouvez créer un index unique sur le "nom d'utilisateur", mais vous avez alors deux index uniques, l'un qui est utile et l'autre qui est juste un nombre aléatoire.
- Vous y ferez référence partout. Les données de vos utilisateurs seront généralement réparties sur plusieurs collections, toutes avec un pointeur vers le "userId". Avoir des ObjectIds (ou Guids), signifie que vous copiez-collez constamment ces gros identifiants partout et que vous les stockez dans la base de données.
Transféré où ? Une fois que vous commencez à stocker les données de l'utilisateur dans MongoDB, les identifiants seront le moindre de vos problèmes de transfert vers une autre base de données. Toutes les bases de données modernes peuvent gérer une forme de chaîne ou de binaire comme ID de clé primaire, de sorte que votre transfert devrait fonctionner correctement. Mais la plus grande partie de la complexité n'aura rien à voir avec l'ID.
