Relaciones uno a uno embebidas en MongoDB

Contenido del curso

Introducción

Proyecto

Validación de datos

Relaciones

Bonus: patrones

Próximos pasos

22
Modelado de Datos con MongoDB: Relaciones y Consultas Avanzadas
02:03 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0010:09

Relaciones uno a uno embebidas en MongoDB

Curso de Modelado de Datos en MongoDB

Clase 13 de 22

Clase 13 / 22

Recursos

Cuando modelas datos en MongoDB, una de las primeras decisiones que enfrentas es cómo representar las relaciones uno a uno. La forma embebida resuelve la mayoría de estos casos y simplifica tanto las consultas como el rendimiento, especialmente cuando la información depende directamente del documento principal.

¿Qué es una relación uno a uno embebida en MongoDB?

Es una forma de modelar datos donde un documento incluye dentro de sí mismo un subdocumento que le pertenece de manera exclusiva. En lugar de dispersar atributos repetidos como calle, ciudad y código postal en el documento del usuario, agrupas esa información en un subdocumento llamado address.

¿Cuándo conviene embeber en lugar de referenciar? Cuando la información se consulta junto al documento principal y depende directamente de él, como la dirección de un usuario o los ítems de una orden de compra.

Imagina un usuario en un e-commerce que tiene dos direcciones: la de residencia y la de envío o shipping address. Si dejas todo plano, terminas con atributos duplicados. Si lo embebes, cada dirección queda contenida como un subdocumento ordenado y fácil de leer [01:30].

¿Cómo se modela un usuario con dirección embebida en el código?

En la práctica, creas el documento del usuario con sus campos básicos (email, password, role) y agregas los subdocumentos que representan las direcciones.

js db.users.insertOne({ email: "user@gmail.com", password: "...", role: "customer", address: { street: "Carrera 87", city: "Bogotá", zip: "..." }, shippingAddress: { street: "Oficina", city: "Bogotá", zip: "..." } })

Esta estructura asume que cada usuario tiene una y solo una dirección de residencia y una sola dirección de envío. Si tu e-commerce necesitara soportar múltiples direcciones de envío, esa relación dejaría de ser uno a uno y pasaría a ser uno a muchos [04:20].

¿Cómo consultar campos dentro de un subdocumento?

La gran ventaja de embeber es que puedes filtrar por campos del subdocumento usando notación de punto. Por ejemplo, para encontrar todos los usuarios que viven en Bogotá:

js db.users.find({ "address.city": "Bogotá" }) db.users.find({ "address.city": "Bogotá" }).count()

La expresión "address.city" indica que estás accediendo al campo city dentro del subdocumento address. Si tienes dos usuarios, uno en Cali y otro en Bogotá, el count devolverá 1 y el find traerá solo el documento que coincide [07:40].

¿Qué hace la notación de punto en MongoDB? Permite consultar campos anidados dentro de subdocumentos sin necesidad de operadores adicionales. Escribes "campo.subcampo" y MongoDB resuelve la jerarquía automáticamente.

¿Por qué las relaciones embebidas mejoran el rendimiento?

Al tener la información dentro del mismo documento, MongoDB no necesita ir a otra colección para resolver la consulta. Cualquier find te trae el documento completo con todas sus relaciones embebidas, sin trabajo adicional. Eso reduce latencia y simplifica el código de la aplicación [09:15].

¿Cuándo deberías embeber una relación uno a uno?

Hay tres señales claras que indican que embeber es la decisión correcta:

La información se consulta en conjunto. Cuando obtienes un usuario, casi siempre quieres también su dirección. No tiene sentido separar lo que siempre se lee junto.
El subdocumento es una dependencia directa. La dirección no existe sin el usuario, igual que los ítems de una orden no existen sin la orden de compra.
El subdocumento se comporta como un atributo extendido. Igual que email o password pertenecen al usuario, address también le pertenece y depende de él.

¿Qué porcentaje de relaciones uno a uno se embeben?

Alrededor del 90% de las veces una relación uno a uno va embebida. Solo en un 10% de los casos tiene sentido expresarla de forma referenciada, y son situaciones muy específicas que vale la pena analizar aparte [11:50].

Habilidades y conceptos que practicas con este modelo

Trabajar con relaciones uno a uno embebidas te entrena en varias capacidades clave del modelado NoSQL:

Modelado de subdocumentos: aprendes a identificar cuándo un grupo de campos pertenece como bloque a otro documento.
Notación de punto en consultas: dominas el acceso a campos anidados con sintaxis como "address.city".
Operaciones básicas: practicas insertOne, find, count y drop para gestionar tu colección desde cero.
Criterios de diseño: desarrollas el criterio para decidir entre embeber y referenciar según cómo se consulta la información.

El siguiente paso es entender ese 10% restante: cuándo una relación uno a uno conviene expresarla con referencia en lugar de embeberla. ¿Tú ya identificaste alguna relación uno a uno en tu proyecto que valga la pena embeber? Cuéntame en los comentarios cómo la modelarías.

Sebastián Groselj Pausic

Hace 3 años

Relaciones 1 a 1 embebidas

La utilizamos cuando tenemos una dependencia interna de ciertos atributos que estan relacionados o que se repiten para diferentes casos. Entonces se realizaran subdocumentos que contengan esos atributos relacionados.

Casos recomendables de uso

En el 90% de los casos, cuando hay una relacion 1:1, esta suele ser embebida.

Cuando la informacion se consulta en conjunto
Los sub-documentos sean una dependencia directa

Por ejemplo:

Tenemos en una tienda online un usuario que tiene una direccion de su casa y otra de envio. Estas direcciones tienen varios atributos que comparten y para cada uno estan relacionados.

Entonces agrupamos estas propiedades en sub-documentos (objetos) en direccion casa y direccion de envio.

Insertar datos para embebed 1-1

db.users.insertOne({ // insertar un documento
    name: "pam", // propiedad del documento
    address: { // subdocumento (Embebido)
        street: "Calle falsa 123", // propiedad del subdocumento
        city: "Sprinfield",
        zip: 1234
    },
    shipping_address: {
        street: "Calle falsa 124",
        city: "Sprinfield",
        zip: "1235"
    }
})

Consultar datos en embebed 1-1

db.users.find({
    "address.city": "Sprinfield" // Filtrar con una propiedad de un sub-documento
})

Introducción

Modelado de datos en MongoDB desde cero

Modelado de Datos en MongoDB: Uso de JSON y Diagrama Entidad-Relación

Metodología de modelado de datos en MongoDB

Proyecto

Creación de Clúster y Bases de Datos en Mongo Atlas

Modelado de Workloads en Bases de Datos con MongoDB

Configuración de Entorno y Conexión a MongoDB con VSCode

Validación de datos

Validación de strings con JSON Schema en MongoDB

Validación de números, booleanos y enums en MongoDB

Validar arrays y subdocumentos en MongoDB

Validar contraseñas en MongoDB con regex

Validación de Datos en MongoDB: JSON Schema y Actualizaciones

Relaciones

Relaciones en Bases de Datos NoSQL: Embebidas y Referenciales

Relaciones uno a uno embebidas en MongoDB

Relaciones uno a uno con $lookup en MongoDB

Relaciones Uno a Muchos: Embebidas y Referenciadas en Bases de Datos

Relaciones Uno a Muchos con Referencias en Bases de Datos

Relaciones Muchos a Muchos en Bases de Datos: Tiendas y Productos

Relaciones Muchos a Muchos en Bases de Datos Documentales

Bonus: patrones

Desnormalización en Bases de Datos Documentales: Optimización Avanzada

Computed pattern en MongoDB para totales

Balance entre Simplicidad y Rendimiento en MongoDB

Próximos pasos

Modelado de Datos con MongoDB: Relaciones y Consultas Avanzadas

Relaciones uno a uno embebidas en MongoDB

Progreso del curso

Introducción

Proyecto

Validación de datos

Relaciones

Bonus: patrones

Próximos pasos

Recursos

Recursos