MongoDB modela relaciones (uno-a-uno, uno-a-muchos, muchos-a-muchos) mediante incrustar o referenciar — la elección depende de la cardinalidad de la relación, cómo se acceden los datos y si se comparten. A diferencia del enfoque uniforme de clave foránea de SQL, MongoDB ofrece flexibilidad por relación.
{ : (), : , : { : , : } }
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] } // a few addresses
// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection: { _id: "b1", authorId: "a1", title: "..." } // each book references its author
// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
El matiz clave: uno-a-pocos (incrustar), uno-a-muchos (referenciar desde el lado muchos), uno-a-millones (siempre referenciar — nunca incrustar datos sin límite, debido al límite de 16MB del documento y rendimiento).
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] } // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] } // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
Muchos-a-muchos utiliza arrays de ids referenciados (en uno o ambos lados), o una colección separada similar a una tabla de unión para datos de relación enriquecidos.
// join referenced data when needed
db.books.aggregate([
{ $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
Modelar relaciones es fundamental para el diseño de bases de datos, y el enfoque flexible de MongoDB, impulsado por patrones de acceso, es diferente de las claves foráneas uniformes de SQL, por lo que comprender cómo modelar relaciones en MongoDB es esencial para diseñar esquemas efectivos.
La perspectiva clave es que MongoDB modela relaciones mediante incrustar o referenciar basándose en las características de la relación — y entender cómo la cardinalidad afecta la elección es la habilidad crucial: uno-a-uno (normalmente incrustar — accedidos juntos), uno-a-muchos con sus matices importantes (uno-a-pocos → incrustar para datos acotados accedidos juntos; uno-a-muchos → referenciar desde el lado muchos; uno-a-millones → siempre referenciar, nunca incrustar datos sin límite debido al límite de 16MB del documento y rendimiento), y muchos-a-muchos (arrays de ids referenciados, o una colección similar a una tabla de unión).
Esta toma de decisiones impulsada por cardinalidad (especialmente reconocer cuándo los datos son demasiado grandes/sin límite para incrustar) es esencial para evitar errores comunes como incrustar arrays sin límite (inflando documentos, alcanzando límites) o sobre-referenciar datos que deberían estar incrustados.
Entender cómo resolver referencias con $lookup cuando se necesitan uniones completa el panorama.
Ya que las relaciones entre entidades son inherentes en la mayoría de modelos de datos, y ya que el enfoque flexible de MongoDB por relación (incrustar vs referenciar basado en cardinalidad y patrones de acceso) es fundamentalmente diferente y más matizado que las claves foráneas uniformes de SQL, entender cómo modelar relaciones en MongoDB — las decisiones de incrustar/referenciar basadas en cardinalidad (especialmente la distinción uno-a-pocos/muchos/millones) y resolver referencias — es conocimiento esencial, aplicado frecuentemente, para un diseño de esquema MongoDB efectivo, construyendo sobre los fundamentos de incrustar/referenciar para manejar las relaciones que toda aplicación real tiene, y una área clave que distingue el modelado MongoDB correcto de puertos ingenuos de relaciones.