Alguns que eu vi:
- Não é ótimo para URLs. O Twitter me dá um URL como http://twitter.com/gatesvp , com um ObjectId você obtém um URL como http://example.com/ab12ab12ab12ab12ab12ab12 .
- Os fragmentos do ObjectId são muito ruins. Não é realmente aleatório, é um pouco sequencial, então novos usuários se agruparão em fragmentos em vez de distribuir aleatoriamente.
- Você geralmente precisa de outro identificador exclusivo. A maioria dos sites exige um e-mail exclusivo ou um nome de usuário exclusivo. Sim, você pode criar um índice exclusivo no "nome de usuário", mas você tem dois índices exclusivos, um que é útil e outro que é apenas um número aleatório.
- Você fará referência a isso em todos os lugares. Os dados de seus usuários normalmente serão distribuídos em várias coleções, todas com um ponteiro para o "userId". Ter ObjectIds (ou Guids) significa que você está constantemente copiando e colando esses grandes IDs em todos os lugares e armazenando-os no banco de dados.
Transferido para onde? Assim que você começar a armazenar os dados do usuário no MongoDB, os IDs serão o menor dos seus problemas para transferir para outro banco de dados. Todos os bancos de dados modernos podem lidar com alguma forma de String ou Binary como o ID da chave primária, portanto, sua transferência deve funcionar bem. Mas a maior parte da complexidade não terá nada a ver com o ID.
