Relación uno a muchos en MongoDb

En MongoDB, una relación uno a muchos (1:N) significa que un documento principal puede estar relacionado con varios documentos secundarios. Es uno de los tipos de relación más comunes en bases de datos.

¿Qué es una relación uno a muchos?

Una relación uno a muchos ocurre cuando un registro puede tener múltiples registros asociados.

Ejemplo:

• Un cliente puede tener muchos pedidos.
• Un autor puede tener muchos libros.
• Un departamento puede tener muchos empleados.

Representación conceptual:

¿Cómo se maneja en MongoDB?

MongoDB no utiliza claves foráneas como MySQL o PostgreSQL. En su lugar, existen dos estrategias principales:

• Documentos embebidos (Embedded Documents)
• Referencias entre colecciones (References)

Opción 1: Documentos embebidos

Consiste en almacenar los documentos hijos dentro del documento padre.

Supongamos un cliente con varios teléfonos.

Ejemplo

{
    "_id": ObjectId("1"),
    "nombre": "Oscar Fernandez",
    "correo": "oscar@email.com",
    "telefonos": [
        {
            "numero": "3001234567",
            "tipo": "Movil"
        },
        {
            "numero": "6015551234",
            "tipo": "Casa"
        }
    ]
}

Aquí existe una relación uno a muchos:

• 1 Cliente
• Muchos teléfonos

Los teléfonos están almacenados dentro del mismo documento.

Ventajas

• Consultas muy rápidas.
• No requiere JOIN.
• Menos consultas a la base de datos.

Desventajas

• El documento puede crecer demasiado.
• Límite de 16 MB por documento.
• No es recomendable cuando existen miles de registros hijos.

Opción 2: Referencias

Consiste en almacenar los documentos en colecciones separadas y relacionarlos mediante identificadores.

Colección clientes

{
    "_id": ObjectId("100"),
    "nombre": "Oscar Fernandez",
    "correo": "oscar@email.com"
}

Colección pedidos

{
    "_id": ObjectId("500"),
    "clienteId": ObjectId("100"),
    "producto": "Laptop",
    "cantidad": 1
}

{
    "_id": ObjectId("501"),
    "clienteId": ObjectId("100"),
    "producto": "Mouse",
    "cantidad": 2
}

La relación se establece mediante el campo clienteId.

Visualmente:

Cliente 100
    |
    +-- Pedido 500
    |
    +-- Pedido 501

Ventajas

• Escala mejor.
• Permite millones de documentos relacionados.
• Evita documentos gigantes.

Desventajas

• Se necesitan consultas adicionales.
• Puede requerir Aggregation Framework con $lookup.

Consultar la relación con $lookup

MongoDB ofrece el operador $lookup, similar a un JOIN de SQL.

db.clientes.aggregate([
    {
        $lookup: {
            from: "pedidos",
            localField: "_id",
            foreignField: "clienteId",
            as: "pedidos"
        }
    }
]);

Resultado:

{
    "_id": ObjectId("100"),
    "nombre": "Oscar Fernandez",
    "correo": "oscar@email.com",
    "pedidos": [
        {
            "_id": ObjectId("500"),
            "producto": "Laptop",
            "cantidad": 1
        },
        {
            "_id": ObjectId("501"),
            "producto": "Mouse",
            "cantidad": 2
        }
    ]
}

¿Cuándo usar documentos embebidos y cuándo referencias?

Usar documentos embebidos cuando

• La cantidad de registros hijos es pequeña.
• Los datos siempre se consultan juntos.
• No crecerán demasiado con el tiempo.

Ejemplos:

• Direcciones de un usuario.
• Teléfonos de contacto.
• Configuraciones de perfil.

Usar referencias cuando

• La cantidad de registros hijos puede ser muy grande.
• Los documentos hijos tienen vida propia.
• Los datos se consultan por separado.

Ejemplos:

• Clientes y pedidos.
• Usuarios y publicaciones.
• Productos y ventas.
• Empresas y empleados.

Comparación con SQL

Si vienes de MySQL o PostgreSQL, piensa en la siguiente equivalencia:

SQL

CREATE TABLE clientes (
    id INT PRIMARY KEY,
    nombre VARCHAR(100)
);

CREATE TABLE pedidos (
    id INT PRIMARY KEY,
    cliente_id INT,
    FOREIGN KEY(cliente_id) REFERENCES clientes(id)
);

MongoDB

clientes
{
    "_id": ObjectId("100"),
    "nombre": "Oscar Fernandez"
}

pedidos
{
    "_id": ObjectId("500"),
    "clienteId": ObjectId("100")
}

La diferencia principal es que MongoDB no obliga la integridad referencial. Eres tú quien debe garantizar que el clienteId realmente exista.

Regla práctica para principiantes

Cuando estés diseñando una base de datos MongoDB, hazte esta pregunta:

¿Los datos hijos siempre se consultan junto con el padre y son pocos?

Si la respuesta es sí, utiliza documentos embebidos.

¿Los datos hijos pueden crecer mucho o consultarse por separado?

Si la respuesta es sí, utiliza referencias.

Por ejemplo, en un sistema ERP:

• Cliente → Direcciones → Embebido.
• Cliente → Facturas → Referencias.
• Cliente → Pedidos → Referencias.
• Producto → Imágenes → Embebido.
• Producto → Movimientos de inventario → Referencias.

Esta forma de pensar es fundamental en MongoDB porque el modelado de datos suele ser más importante que en bases de datos relacionales tradicionales.