Analizar el ObjectId de una solicitud no sería difícil (¿así que no estoy seguro de por qué es un problema?). Si el objetivo es crear direcciones URL que se puedan escribir, sería valioso tener una URL más corta y "más amigable".
No puede tomar un número de 12 bytes que se garantiza único en una configuración fragmentada de MongoDB y condensarlo en menos de 12 bytes y garantizar que sea único (mencionó menos de siete caracteres, por ejemplo).
De los docs , el ObjectId de MongoDB consta de:
- una marca de tiempo de 4 bytes
- un identificador de máquina de 3 bytes
- una identificación de proceso de 2 bytes
- y un contador de 3 bytes.
Por lo tanto, deberá sacrificar una parte del ObjectId (y, por lo tanto, la fragmentación) o diseñar un formato de creación de Id alternativo que esté indexado.
Si bien podría codificar potencialmente la ID, nuevamente, pueden surgir conflictos para los que desea codificar (nuevamente, no puede reducir 12 bytes a 4 bytes y garantizar la exclusividad). Y si es posible que existan conflictos (y los habrá si reduce la cantidad total de bits disponibles), necesitará algún tipo de tabla secundaria de todos modos (y deberá crear un índice para pasar de ID generado a ObjectId) .
Opciones resultantes:
- Elimine partes normalmente significativas; si hace esto, no lo haga. fragmentar la colección
- Diseñe su propia solución de identificación única (y si está en una granja web, puede terminar pareciendo muy similar a la de MongoDB para manejar la unicidad)
- use el ObjectId como un número largo y ejecute un algoritmo de reducción en él (primero deberá dividirse en partes más pequeñas ya que excede la precisión numérica de JavaScript de 53 bits), pruebe este algoritmo, por ejemplo =codificar it (terminará con alrededor de 17 caracteres)
- use algo más corto, pero único, como identificación para sus documentos
- Lo más fácil:simplemente acepte que los identificadores son largos. :)
(No está claro por qué el navegador necesitaría hacer esta conversión, ¿por qué tendría el ObjectID del documento?)
