Alcuni che ho visto:
- Non va bene per gli URL. Twitter mi fornisce un URL come http://twitter.com/gatesvp , con un ObjectId ottieni un URL come http://example.com/ab12ab12ab12ab12ab12ab12 .
- Gli shard ObjectId sono molto scarsi. Non è realmente casuale, è in qualche modo sequenziale, quindi i nuovi utenti si raggrupperanno sugli shard anziché distribuirli in modo casuale.
- Spesso hai bisogno di un altro identificatore univoco. La maggior parte dei siti Web richiede un'e-mail univoca o un nome utente univoco. Sì, puoi creare un indice univoco sul "nome utente", ma poi hai due indici univoci, uno utile e uno che è solo un numero casuale.
- Farai riferimento a questo ovunque. I dati dei tuoi utenti verranno in genere distribuiti su più raccolte, tutte con un puntatore a "userId". Avere ObjectId (o Guid), significa copiare e incollare costantemente questi ID grandi ovunque e archiviarli nel DB.
Trasferito dove? Una volta che inizi a memorizzare i dati dell'utente in MongoDB, gli ID saranno l'ultimo dei tuoi problemi nel trasferimento su un altro DB. Tutti i DB moderni possono gestire una qualche forma di String o Binary come ID della chiave primaria, quindi il tuo trasferimento dovrebbe funzionare correttamente. Ma la maggior parte della complessità non avrà nulla a che fare con l'ID.
