Skip to content

Modelado de documentos

En MongoDB se modela pensando en como se accede a los datos. La pregunta principal es: que necesita leer o escribir la aplicacion en una sola operacion.

Documento

javascript
{
  _id: ObjectId("..."),
  nombre: "Ana",
  email: "ana@example.com",
  direccion: {
    ciudad: "Madrid",
    codigo_postal: "28001"
  },
  tags: ["vip", "newsletter"]
}

Embebido

Embebe datos que se leen siempre juntos y no crecen sin limite.

javascript
{
  _id: ObjectId("..."),
  cliente: "Ana",
  lineas: [
    { sku: "TEC-001", cantidad: 1, precio: 49.99 },
    { sku: "RAT-002", cantidad: 2, precio: 19.99 }
  ]
}

Referencias

Referencia cuando los datos crecen mucho, se comparten o cambian de forma independiente.

javascript
{
  _id: ObjectId("..."),
  cliente_id: ObjectId("..."),
  total: 89.97
}

Validacion de esquema

javascript
db.createCollection("clientes", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["nombre", "email"],
      properties: {
        nombre: { bsonType: "string" },
        email: { bsonType: "string" }
      }
    }
  }
})

Buenas practicas

  • Modela segun consultas reales.
  • Embebe cuando el documento se consume junto.
  • Referencia cuando hay crecimiento ilimitado.
  • Evita arrays gigantes.
  • Guarda campos derivados solo con estrategia de sincronizacion.

Errores comunes

  • Modelar como si fuera SQL.
  • Duplicar datos sin plan de actualizacion.
  • Crear documentos demasiado grandes.
  • No validar campos criticos.
  • No pensar en indices desde el modelado.