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.