Nivel 1 · 20 min

Modelado de Datos

El modelo de documento flexible de MongoDB permite estructuras de datos ricas, pero las decisiones de schema tomadas temprano son difíciles de revertir. Entender cuándo embeber vs referenciar datos es la decisión de diseño más crítica en MongoDB.

Embedding vs Referencing

Embedding coloca datos relacionados dentro del mismo documento. Ideal para: datos accedidos juntos (elimina joins), datos con crecimiento acotado (los arrays embebidos siguen siendo manejables), relaciones uno-a-uno o uno-a-pocos, datos que pertenecen al padre (una dirección pertenece a un usuario). Referencing almacena una clave foránea (ObjectId) apuntando a otra colección. Ideal para: datos grandes o sin límite (comentarios en un post viral), datos compartidos entre muchos documentos, datos accedidos independientemente. La clave: MongoDB no tiene joins server-side por defecto: cada referencia requiere una query separada o un $lookup.

Patrones de Relaciones 1-N

Tres patrones para relaciones uno-a-muchos. Array embebido (uno-a-pocos): embebé el lado N como array en el documento padre. Simple, lecturas rápidas, pero los arrays deben permanecer acotados (límite de 16 MB). Referenciado (uno-a-muchos): los documentos del lado N tienen cada uno un campo parent_id. Permite N sin límite, habilita querying independiente. Extended reference (uno-a-muchísimos): cuando N es realmente enorme (eventos IoT, logs), almacená el parent_id en los documentos hijo y desnormalizá un subconjunto de campos padre en cada hijo.

Anti-patrones de Schema

Arrays masivos: embeber un array sin límite arriesga alcanzar el límite de 16 MB y causa actualizaciones lentas. Documentos inflados: embeber datos raramente accedidos aumenta la presión de memoria. Índices innecesarios: cada índice cuesta overhead de escritura y RAM. Normalización por sí misma: a diferencia de SQL, normalizar para eliminar toda duplicación a menudo perjudica la performance en MongoDB: la desnormalización controlada es idiomática.

Puntos clave

Embebé cuando los datos se acceden juntos y tienen crecimiento acotado. Referenciarlos cuando son sin límite, compartidos o se consultan independientemente.
MongoDB no tiene joins server-side: cada $lookup es costoso. Diseñá schemas según tus patrones de query, no según la teoría de normalización.
El límite de 16 MB en documentos es una restricción dura en arrays embebidos. Diseñá pensando en el crecimiento futuro.

Code example

// Embedding (one-to-few, bounded)\n{\n  "_id": "post_1",\n  "title": "MongoDB Data Modeling",\n  "tags": ["mongodb", "nosql", "database"],\n  "author": {"name": "Alice", "email": "[email protected]"}\n}\n\n// Referencing (one-to-many, unbounded)\n// Comment document: {"post_id": "post_1", "body": "...", "user_id": "user_1"}\n// Query comments: db.comments.find({post_id: 'post_1})