Relaciones entre documentos

Clase 14 de 26 • Curso Básico de MongoDB

Resumen

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.

Juan Castro

teacher•

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!

Fernando Azuaje

student•

La verdad que si esta increible

Usuario anónimo

user•

Es excelente.

Saúl Báez Terrez

student•

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

Robinson Moreno

student•

Simple,

si la informacion esta sujeta a cambio se realizar una coleccion "editorial" que contenga esos parametros que pueden cambiar.
Ese dato lo referencias en tu collecion "main".

3.Cuando actualices la informacion en la coleccion "editorial" se actualizara la info de tu coleccion "main" -Y asi no tendras que hacer cambios 1 a 1

JOHAN SOTO

student•

Te lo explico facil. Tienes dos colleciones -Libros -Editorial Relación -El valor de campo id de Editorial lo tienes en la tabla de Libros *Cuando busques en libros por ese campo que es iguale en ambas tablas te salen todos los libros de esa editorial *La tabla Editorial es completamente aparte, si la quieres actualizar los haces. *Para tener la información de ambas tablas que están separadas es por medio de agregaciones (un Joins) esta función de sirve para consultar valores de varias tablas en un llamado

POR ESO SE LLAMA REFERENCIA. Referencias tablas(colecciones) por medio de un campo del mismo valor, pero realmente no están unidas las tablas

Félix Andersson

student•

Rodolfo Ugalde Ochoa

student•

Muy buen ejemplo!

omar garcia garcia

student•

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

Emmanuel Rodríguez

student•

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"

OSCAR DARIO PAZ BENAVIDES

student•

Muy buena explicación me quedó más claro :D :D. Ya que vengo de SQL y si me está pateando el trasero esto jeje.

Francisco Garcia [C6]

student•

Es el mismo principio de las bases de datos relacionales

José Alberto Ortiz Vargas

student•

Exacto, y aquí es cuando no le encuentro sentido usar MongoDB.

José Guillermo

student•

Quizá es irónico que las bases de datos no relacionales utilicen relaciones justo como las bases de datos relacionales lo hacen... La forma en que yo lo veo es que los puntos más fuertes de NoSQL es la velocidad de consulta por la ligereza de las estructuras y su característica shema-less.

Luis Fernando Zarazua Aguilar

student•

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.

Carlos S. Aldazosa

student•

Entonces MongoDB no es bueno para hacer updates masivos?

Cesar Augusto Herrera Rosales

student•

Bajo el concepto de "transacción", no. Dado que dentro de los updates masivos es posible que no todos logren ser actualizados.

Carlos S. Aldazosa

student•

Gracias!

JONATAN CADAVID TORRES

student•

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.

William Schnaider Torres Bermon

student•

Model Relationships Between Documents

Alexander Moreno Córdoba

student•

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":"prueba@email.com",
	    "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"

	}

TIQAL SAS

student•

cual es la mejor estrategia para relaciones muchos a muchos ???

Marco Antonio Macedo Preciado

student•

Colecciones separadas con un arreglo de Ids

Johan Garzon

student•

Minuto 2:30 en adelante. Realizar operaciones update dentro de MongoDB no son transaccionales. ¿Que quiere decir? El ejemplo que se da despues no genera confianza en cuanto a los updates en Mongo. Suena como que Mongo no siguiera ordenes sino que haría update a los que quiere.

Carlos Herrera

student•

Las transacciones en las bases de datos relacionales se enfocan en que haya seguridad de la información, quiere decir que al ejecutar los query no se guardaran cambios hasta que se hayan ejecutado correctamente todos los query, para esto se usan las sentencias BEGIN, COMMIT y ROLLBACK siempre inicia BEGIN y luego los query a ejecutar, al finalizar se puede colocar COMMIT para que guarde los cambios si se ejecuto correctamente lo que esta entre el begin y el commit.

Si por alguna razon hay un error entre lo que esta consultado entre el bloque de inicio y final el commit no guardara cambios.

Con ROLLBACK se deshace la transacción, así este correcta toda la consulta en el interior del bloque.

Jenner SocorroArias

student•

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

Juan Guillermo Perez Cardozo

student•

bueno el ejemplo de libros y editorial

Johnner Alexander Gambacica Ortiz

student•

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

Reinaldo Mendoza

student•

esa fue una de las cosas que me quedo clara y me parece una ventaja frente a sql

Wandy Rafael Santana Evangelista

student•

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

Usuario anónimo

user•

MongoDB es genial

Jorge Jorquera

student•

se supone que mongoDB esta pensado en noSQL y el modelado lo están forzando a que sea SQL, no tiene sentido si van a empezar hablar de relaciones y entidades, para eso están las SQL, el curso no enseña como modelar un problema pensado en colecciones y documentos, es un chambonada lo que hacen

JONATAN CADAVID TORRES

student•

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.

Amin Alejandro Lugo Cruz

student•

En lo que he vivenciado y entendido del concepto todo se encamina a que los SGBD como SQLSever, Oracle, DB2, MySQL entre otros se orientan al diseño relacional, lo que te explicaban en la universidad, mientras que en NoSQL este concepto cambia a tal punto que tienes la capacidad de convertir una "tabla" en el registro de otra, como lo puede una BD clave-valor solo para nombrarte una de las diferentes posibilidades que se ofrecen dependiendo de la software que uses. Tal vez estos artículos te pueda orientar mucho mas frente a la duda que tienes

Alexander Moreno Córdoba

student•

Que otras ventajas tenemos de las relaciones entre documentos cuando lo comparamos con SQL?

Relaciones entre documentos

Introducción

Qué aprenderás sobre MongoDB

Bases de datos NoSQL

Definición de MongoDB y su ecosistema (herramientas de uso)

MongoDB Atlas

Instalación MongoDB en Windows

Instalación MongoDB Mac/Linux

Mongo Shell, configuración de clientes

MongoDB + Drivers

Operaciones CRUD

Bases de datos, Colecciones y Documentos en MongoDB

Operaciones CRUD desde la consola de MongoDB

Operaciones CRUD desde Compass

Esquemas y relaciones

Tipos de datos

¿Qué son los esquemas y las relaciones?

Relaciones entre documentos

Profundización de queries dentro de MongoDB

Operadores para realizar queries y proyecciones

Usando operadores para realizar Updates en arreglos

Operaciones avanzadas con Agregaciones

Python con MongoDB (opcional)

Configuración e instalación de dependencias para el proyecto PlatziMongo

Operaciones CRUD con Python y Pymongo

Diseñando el esquema de clases, cursos y carreras

Ejecución de queries

Relaciones

Consultas más rápidas con Índices

Recomendaciones para poner en producción tu cluster de Atlas

Recomendaciones de Arquitectura y Paso a Producción

Nuestra base de datos en un cluster de producción

Conclusiones

Resumen y Conclusiones