ventajas tutorial example desventajas descargar caracteristicas mongodb

tutorial - MongoDB y "une"



mongodb ventajas y desventajas (11)

A partir de Mongo 3.2, la respuesta a esta pregunta ya no es correcta. El nuevo operador de búsqueda $ agregado a la canalización de agregación es esencialmente idéntico a una combinación externa izquierda:

docs.mongodb.org/master/reference/operator/aggregation/lookup/…

De los documentos:

{ $lookup: { from: <collection to join>, localField: <field from the input documents>, foreignField: <field from the documents of the "from" collection>, as: <output array field> } }

Esta pregunta ya tiene una respuesta aquí:

Estoy seguro de que MongoDB no admite oficialmente "join". ¿Qué significa esto?

¿Significa esto que "no podemos conectar dos colecciones (tablas) juntas"?

Creo que si ponemos el valor de _id en la colección A en la other_id en la colección B, ¿podemos simplemente conectar dos colecciones?

Si mi comprensión es correcta, MongoDB puede conectar dos tablas juntas, por ejemplo, cuando ejecutamos una consulta. Esto se hace mediante "Referencia" escrito en http://www.mongodb.org/display/DOCS/Schema+Design .

Entonces, ¿qué significa realmente "une"?

Me encantaría saber la respuesta porque es esencial para aprender el diseño del esquema de MongoDB. http://www.mongodb.org/display/DOCS/Schema+Design

Como soy un usuario de MongoDB, tuve que buscar datos de colecciones relacionadas con bastante frecuencia. Cuando las personas almacenan datos de bases de datos relacionales en bases de datos NoSQL, se hace necesario "unir". Aquí hay una biblioteca que yo, junto con mi amigo, hemos creado para realizar Mongo Joins en Python:

https://pypi.python.org/pypi/mongojoin/1.0.0

¡El código no es demasiado complicado y vale la pena intentarlo!

Considera usar la mangosta? Te da la posibilidad de hacer combinaciones en datos de mongo.

El hecho de que mongoDB no es relacional ha llevado a algunas personas a considerarlo inútil . Creo que debes saber lo que estás haciendo antes de diseñar una base de datos. Si opta por no utilizar DB de SQL, como MongoDB, es mejor implementar un esquema. Esto hará que sus colecciones, más o menos, se asemejen a tablas en bases de datos SQL. Además, evite la desnormalización (incrustación), a menos que sea necesario por razones de eficiencia.

Si desea diseñar su propia base de datos noSQL, le sugiero echar un vistazo a la documentación de Firebase . Si comprende cómo organizan los datos para su servicio, puede diseñar fácilmente un patrón similar para el suyo.

Como otros señalaron, tendrá que hacer las uniones del lado del cliente, excepto que con Meteor (un marco de JavaScript), puede hacer sus uniones del lado del servidor con este package (no conozco otro framework que le permita hacer asi que). Sin embargo, le sugiero que lea este article antes de decidirse por esta opción.

Editar 28.04.17: Recientemente Firebase publicó esta excelente serie sobre el diseño de bases de datos noSql. También destacaron en uno de los episodios las razones para evitar uniones y cómo sortear tales escenarios mediante la desnormalización de su base de datos.

El primer ejemplo al que se vincula muestra cómo las referencias de MongoDB se comportan de forma similar a la carga diferida, no como una combinación. No hay una consulta que esté ocurriendo en ambas colecciones, sino que consulta una y luego busca elementos de otra colección por referencia.

Encontré muchas publicaciones buscando lo mismo - "Mongodb se une" y alternativas o equivalentes. Entonces mi respuesta ayudaría a muchos otros que son como yo. Esta es la respuesta que estaría buscando.

Estoy usando Mongoose con Express framework. Hay una funcionalidad llamada Population en lugar de uniones.

Como se menciona en los populate Mongoose.

No hay uniones en MongoDB, pero a veces todavía queremos referencias a documentos en otras colecciones. Aquí es donde entra la población.

Esta respuesta muestra un ejemplo simple sobre cómo usarlo.

La base de datos no hace combinaciones, o "enlaces" automáticos entre documentos. Sin embargo, puede hacerlo usted mismo desde el lado del cliente. Si necesita hacer 2, está bien, pero si tuviera que hacer 2000, la cantidad de cambios de cliente / servidor haría que la operación fuera lenta.

En MongoDB, un patrón común es la incrustación. En relacional cuando se normalizan las cosas se dividen en partes. A menudo, en mongo estas piezas terminan siendo un documento único, por lo que no es necesario unirse de todos modos. Pero cuando uno es necesario, uno lo hace desde el lado del cliente.

Considere el clásico ORDER, ORDER-LINEITEM ejemplo. Un pedido y 8 artículos de línea son 9 filas en relacional; en MongoDB normalmente solo modelaríamos esto como un único documento BSON que es un pedido con una matriz de elementos de línea integrados. Entonces, en ese caso, el problema de unirse no surge. Sin embargo, el pedido tendría un CLIENTE que probablemente sea una colección separada: el cliente podría leer el cust_id del documento de pedido y luego ir a buscarlo según sea necesario por separado.

Hay algunos videos y diapositivas para las charlas de diseño de esquema en el sitio web mongodb.org que creo.

No es una unión ya que la relación solo se evaluará cuando sea necesario. Una unión (en una base de datos SQL) por otra parte resolverá las relaciones y las devolverá como si fueran una sola tabla ("unir dos tablas en una sola").

Puede leer más sobre DBRef aquí: http://docs.mongodb.org/manual/applications/database-references/

Hay dos soluciones posibles para resolver referencias. Una es hacerlo manualmente, como casi has descrito. Simplemente guarde el _id de un documento en other_id de otro documento, luego escriba su propia función para resolver la relación. La otra solución es usar DBRefs como se describe en la página del manual anterior, lo que hará que MongoDB resuelva la relación cliente- demanda. La solución que elija no importa tanto porque ambos métodos resolverán la relación del lado del cliente (tenga en cuenta que una base de datos SQL resuelve las uniones en el lado del servidor).

Si usa mangosta, puede usar (suponiendo que esté utilizando subdocumentos y población):

Profile.findById profileId .select ''friends'' .exec (err, profile) -> if err or not profile handleError err, profile, res else Status.find { profile: { $in: profile.friends } }, (err, statuses) -> if err handleErr err, statuses, res else res.json createJSON statuses

Recupera Statuses que pertenecen a uno de los amigos Profile ( profileId ). Friends es una serie de referencias a otros Profiles . Esquema de Profile con friends definidos:

schema = new mongoose.Schema # ... friends: [ type: mongoose.Schema.Types.ObjectId ref: ''Profile'' unique: true index: true ]

un tipo de combinación de una consulta en mongoDB, es solicitar en una colección el id que coincida, poner identificadores en una lista (idlist) y encontrar el uso en otra (o misma) colección con $ in: idlist

u = db.friends.find({"friends": something }).toArray() idlist= [] u.forEach(function(myDoc) { idlist.push(myDoc.id ); } ) db.family.find({"id": {$in : idlist} } )