relaciones - Diferencia entre almacenar un ObjectId y su forma de cadena, en MongoDB
objectid mongodb (2)
Estoy un poco confundido por el uso de ObjectIds por parte de Mongo DB. Seguro que son excelentes para crear identificaciones del lado del cliente que casi definitivamente no entran en conflicto con otras identificaciones creadas del lado del cliente. Pero el mongo parece almacenarlos de alguna manera especial. Almacenar una representación de cadena de la ID es diferente de almacenar una ID de objeto como un objeto. ¿Por qué es esto?
¿No tiene la forma de cadena toda la misma información que tiene la forma del objeto? ¿Por qué el mongo se esfuerza tanto para diferenciar esas dos formas? Me fastidia cuando trato de comparar _ids enviados desde una interfaz de usuario, por ejemplo. Mi base de datos no es en absoluto coherente con el hecho de que almacene los identificadores de forma de cadena o los identificadores de forma de objeto, y aunque mi código es ciertamente parte de la culpa, yo culpo principalmente a mongo por hacer esto tan extraño.
¿Estoy equivocado de que esto es raro? ¿Por qué el mongo lo hace de esta manera?
ObjectId
es de 12 bytes cuando se almacena internamente, lo que es más compacto que la representación de cadena hexadecimal. Los dos son cosas diferentes.
Puede reubicar toda su base de datos y usar un campo uniforme _id
para resolver esto y asegurarse de que su código se guarde en el mismo formato. ObjectId
son rápidos de generar por MongoDB, así que lo usaría al crear nuevos documentos.
Yo, personalmente, culpo a tu código. Evito esto perfectamente bien en mis aplicaciones mediante la codificación de la manera correcta. Convierto a una cadena en el código para comparar y me aseguro de que cualquier cosa que se parezca a un ObjectId
se use realmente como un ObjectId
.
Es bueno tener en cuenta que entre el ObjectId
( http://docs.mongodb.org/manual/reference/object-id/ ) y su representación hexadecimal hay de hecho 12 bytes de diferencia, el ObjectId
12 bytes y es hexadecimal Representación siendo 24.
No solo se trata de la eficiencia del almacenamiento, sino también de los índices; no solo porque son más pequeños, sino también porque ObjectId
se puede utilizar de una manera especial para garantizar que solo se carguen partes del índice; Las partes que se utilizan. Esto se hace más notorio cuando se inserta, donde solo se debe cargar la última parte de ese índice para garantizar la singularidad. No se puede garantizar tal comportamiento con su representación hexadecimal.
Recomiendo encarecidamente que no utilice la representación hexadecimal de OjbectId
. Si quiere "hacer su vida más fácil", sería mejor crear un _id
diferente, que sea más pequeño pero, de alguna manera, igual de único y fácil de indexar.