Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Relaciones entre documentos

14/26
Recursos

Las documentos embebidos nos ayudan a guardar la información en un solo documento y nos ahorra el tiempo que tardamos en consultar diferentes documentos a partir de referencias. Sin embargo, las referencias siguen siendo muy importantes cuando debemos actualizar información en diferentes lugares de forma continua.

Aportes 27

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

  • One to one: Documentos embebidos
  • One to many: Documentos embebidos cuando la información no va a cambiar muy frecuentemente y referencias cuando si.

¡MongoDB es genial!

4:14 pésima explicación, debieron regrabar esta parte

Para los que esten viendo esto, a partir de la 4.0/4.2 ya puedes hacer transactions en mongodb.
https://www.mongodb.com/transactions

Modelado
Modelado: One-to-Few

> db.person.findOne()
{
  name: 'Kate Monster',
  ssn: '123-456-7890',
  addresses : [
     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
  ]
}

Este diseño tiene todas las ventajas y desventajas de los documentos embebidos.

La principal ventaja es que no tenemos que realizar un “query” por separado; la principal desventaja es que no hay manera de acceder a los detalles embebdios como entidades única.

Modelado: One-to-Many

> db.parts.findOne()
{
    _id : ObjectID('AAAA'),
    partno : '123-aff-456',
    name : '#4 grommet',
    qty: 94,
    cost: 0.94,
    price: 3.99
}
> db.products.findOne()
{
    name : 'left-handed smoke shifter',
    manufacturer : 'Acme Corp',
    catalog_number: 1234,
    parts : [     // array of references to Part documents
        ObjectID('AAAA'),    // reference to the #4 grommet above
        ObjectID('F17C'),    // reference to a different Part
        ObjectID('D2AA'),
        // etc
    ]
}

Este diseño, es un buen caso de uso para referenciar elementos. En la práctica, se posee una eficiencia en las operaciones de consulta aplicando una operación “join”.

Modelado: One-to-Squillions

Un clásico uso para el “parent-referencing” donde las referencias están propagadas entre las colecciones que superan el tamaño de 16MB.

> db.hosts.findOne()
{
    _id : ObjectID('AAAB'),
    name : 'goofy.example.com',
    ipaddr : '127.66.66.66'
}

>db.logmsg.findOne()
{
    time : ISODate("2014-03-28T09:42:41.382Z"),
    message : 'cpu is on fire!',
    host: ObjectID('AAAB')       // Reference to the Host document
}
// find the parent ‘host’ document
> host = db.hosts.findOne({ipaddr : '127.66.66.66'});  // assumes unique index
   // find the most recent 5000 log message documents linked to that host
> last_5k_msg = db.logmsg.find({host: host._id}).sort({time : -1}).limit(5000).toArray()

Consideraciones

Básicamente se consideran dos factores:

  • ¿Las entidades donde la “N” de “One-to-N” es independiente?
  • Basado en la respuesta, la selección de un esquema dependerá de los siguientes diseño:
    • Ocuparemos el elemento embebido si no se accederá fuera del concepto del objeto padre.
    • Ocuparemos un arreglo de referencias si la cardinalidad será de “One-to-Many” o si los objetos donde “N” deberían estar solos.
    • Si la cardinaliada se valora para “One-to-Squillions”, usar referencias “One-Side”

Lo padre de MongoDb radica en no tener que crear tablas para elementos que son solo referentes a un objeto en particular y al tener arreglos es muy flexible, no tienes que crear forsozamente otra tabla y hacer queries especiales, sino que ya todo está guardado en su debido lugar, mongo permite usar solo las relaciones cuando son solo verdaderamente necesarias y no por restricciones del lenguaje.

Como en todos los modelos de datos, al realizar el diseño de modelado para MongoDB hay que tener en cuenta las propiedades inherentes y los requisitos de los objetos de la aplicación además de las relaciones entre los objetos de ésta. MongoDB también debe reflejar todas estas características.

Cuando pasa el tiempo, la cantidad de datos de la aplicaron va a crecer y ser cambiante lo que implica que se van a definir los tipos de consultas que la aplicación va a requerir. Estas consideraciones y requisitos hacen tomar decisones a los desarrolladores en los modelos de datos normalizando o desnormalizando Colecciones. Estas decisiones implica que en el modelo de datos se almacene la información en un único documento o sin embargo este documento debe describir relaciones empleando relaciones entre documentos.
Decisiones de Modelado:

Las decisiones para el modelado de los datos implica determinar como se debe estructurar los documentos para ganar en eficiencia. Una de las decisiones primordial es cuando debemos de emplear documentos embebidos o referencias a otros documentos
Embedding

Esta decisión implica la desnormalización de los datos, almacenando dos documentos relacionados en un único documento. Las operaciones a este documento son mucho menos costosas para el servidor que las operaciones que involucran múltiples documentos. En general, se debe de emplear este modelo cuando se tienen relaciones del tipo «contiene» entre entidades. Básicamente en relaciones Uno a Uno.

En este ejemplo vemos como el documento dirección se encuentra embebido en el documento usuario


	{
	    "_id":ObjectId("514ed98d44aee1b035ee756f"),
	    "nombre":"Adrian",
	    "apellido":"Alonso",
	    "numerodecontacto":"412312",
	    "direccion":
	        {
	        "tipo":"Calle",
	        "nombre":"Buenavista",
	        "numero":2,
	        "piso": Noveno B,
	        "codigopostal":28823
        },
	    "email":"[email protected]",
	    "password":"example",
	    "privilegios":0
	}

Relaciones Entre Documentos

Este tipo de decisiones se deben de tomar cuando se tienen relaciones Uno a Muchos donde la parte de muchos siempre aparecen o son visionados desde el contexto de sus documentos padres. Por ejemplo en el siguiente ejemplo podemos ver una referencia entre documentos entre la colección Producto y Comentarios del producto. En este caso merece la pena llevar a los comentarios en una nueva colección en vez de embeberlos si los comentarios van a ser referenciados y filtrados por usuario si ese tipo de consultas se requirieren en gran cantidad en la aplicación. Este ejemplo ya nos llevaría a una decisión de modelo.

Sin embargo la referencia Usuario con Comentario se ve claramente que debe ser una referencia entre documentos, ya que el Usuario puede cambiar sus datos en cualquier momento sin que el Comentario se de cuenta, por lo que es importante enlazarlos con una relación aunque perdamos un nivel de indirección a la hora de consultar.


	{
	    "_id": ObjectId("514d920b44ae16d201a3ff51),
	    "nombre":"Capucchino",
	    "precio":20,
	    "marca":"Nescafé",
	    "comentarios":
	        [
	            DBRef("Comentario",
	            ObjectId("514d91a644ae16d201a3ff50"))

	        ]
}
	{
	    "_id" : ObjectId("514d91a644ae16d201a3ff50"),
	    "usuario" : DBRef("Usuario", ObjectId("514ed98d44aee1b035ee756f")),
	    "texto" : "Me gusta"

	}

Es el mismo principio de las bases de datos relacionales

Esta clase me ayudo aclarando todas mis dudas con respecto a como manejar las relaciones en una BD NoSql. Era el punto que mas me llamaba la atenciòn de estas BD. Hay una pregunta que me gustaria responderme, hay operaciones que una BD SQL me permita hacer y una BD NoSql No me permita?, es decir que debilidades tiene una con respecto a la otra.

Si la existencia de un objeto es dependiente entonces seria mejor introducirlo en el objeto del que depende

**MongoDB es lo máximo.**😎

En el ejemplo de Amazon, es perjudicial realizar un UPDATE masivo, al cambiar varios Documentos embebidos de Editorial dentro de la colección de Libros pero porque¿?

La estructura del documento principal en una relación de uno a muchos es
(de esta forma cambias una sola vez la información del editorial)

{
Uno(Editorial)
{
Muchos(Libros)
}
}

El profe dio el Ejemplo al revés
{
Muchos(Libros)
{
Uno(Editorial)
}
}

no me gusto este video se corto de repente y lo deja a uno confundido

Pregunta de examen:
¿Cuál es la mejor forma de hacer relaciones uno a uno dentro de MongoDB?

Relaciones uno a uno: Documentos dentro de otros documentos.
Relaciones uno a muchos: Arreglos de documentos dentro de documentos.
Relaciones uno a muchos (Si los datos cambiarán frecuentemente): Arreglos con los id de referencias (como si fuera una base de datos relacional) O referencias normales.

La verdad esta sección no la entendi en nada.
Espero y alguien me pueda explicar de mejor manera por favor.

y ¿Las relaciones mucho a mucho?

Mongo Lo es todo

bueno el ejemplo de libros y editorial

Entendido. Se puede tener muchas formas para relacionar docuementos.

profe o compañeros, una pregunta; es claro que para relaciones muchos a muchos es posible en mongo y con el ejemplo que nos dio acerca de los cursos de platzi es posible y practico, pero para el manejo de información de usuarios, por ejemplo en la plataforma de platzi, es buena idea utilizar mongo?, para registro de ingresos tipos de usuarios, created_at and updated_at, y todo este tipo de información, que requiere el uso de relaciones donde un cambio que afectara a miles de tablas, como se haría en mongo?

Relaciones 1 a 1 debemos usar documentos enbebidos!

Suena práctico lo que se puede realizar.

con los documentos embebidos es podre los querys no? o depende de como disenaste tu db?

no es por ofender pero el azul de los ejemplos esta muy chillante se confunde con el fondo las letras

Las documentos embebidos nos ayudan a guardar la información en un solo documento y nos ahorra el tiempo que tardamos en consultar diferentes documentos a partir de referencias. Sin embargo, las referencias siguen siendo muy importantes cuando debemos actualizar información en diferentes lugares de forma continua.