Tengo un campo de Id. Único del tipo int en mis documentos. Estoy haciendo ensureIndex en este campo, pero mis documentos aún contienen _id. ¿Puedo deshacerme de eso?MongoDB: ¿es posible evitar el uso del campo _id automático?
Desde el docs ...
Si un usuario intenta insertar un documento sin proporcionar un campo _id, la base de datos generará automáticamente un objeto Identificación y almacenarla el campo _id.
Sin embargo, puede asignar su propio valor a _id ...
valor _ID puede ser de cualquier tipo, aparte de las matrices, con tal de que es un único.
La mejor pregunta es ¿por qué crear su propio identificador único, construir un índice sobre el mismo y retire la gran utilidad de objeto _id que está indexado automático?
Todos los pilotos oficiales de objeto utilizar y tiene una gran cantidad de muy buenos aspectos a ella:
Se ha construido una marca de tiempo en (por lo que no es necesario para almacenar un campo de fecha en su documento, y puede usarlo para ordenar por fecha.)
Es un "número de secuencia global y uniformemente creciente" --- es decir, , seguirá siendo único en todos los servidores si necesita fragmentar sus datos, etc.
No, no puede deshacerse de él, it is there by design, pero puede asignar su identificador único int al al insertar documentos.
Una buena idea sería almacenar su hash en el campo _id.
Por lo tanto, la base de datos no creará automáticamente el campo _id porque ya existirá y ahorrará el espacio de un índice no utilizado.
Simplemente configure el campo _id como cualquier otro con el valor que desee (su hash por ejemplo). ¡Pero ten cuidado, tiene que ser único!
Para garantizar la unicidad deberías o que sea único o poner un subdocumento en el campo _id: {_id: {h: [yourHash], u: [un identificador único]}, ...}
Eso es exactamente lo que hice, matando a dos pájaros de una vez: mis documentos no contienen un ObjectID enorme, y no necesito llamar a 'ensureIndex' después de cada inserción - obtuve una aceleración significativa (nunca pensaría' ensureIndex 'es tan lento). –
@Violet Giraffe: No hay necesidad de llamar a 'ensureIndex' después de cada inserción, solo necesita ser llamado una vez durante la vida de la base de datos, al igual que con MySQL. Además, 'ObjectID' no es realmente un campo 'enorme'. Aún así, estoy de acuerdo en que usar hash tiene sentido. En la discusión de hash vs. id de objeto vs. guid, asegúrese de comprender las implicaciones a largo plazo de la coherencia y las posibles claves de fragmentos. – mnemosyn
Gracias ¡tú! Soy nuevo en MongoDB y he echado de menos la parte de la documentación que ha citado. Y gracias por explicar los beneficios de usar ObjectID. Aún así, quiero usar mi ID porque es un hash (y debo almacenarlo en mi documento de todos modos), y es más pequeño que ObjectID. –
Feliz de ayudar, obviamente se trata de lo que es mejor para su aplicación, pero he encontrado que el ObjectID es muy útil en una serie de situaciones en las que no habría pensado cuando comencé. ¡Diviértete, http://learnmongo.com también puede ser útil para ti! –
¡Gracias por el excelente enlace! –