Bases de documentos
El documento
Cada registro es un objeto tipo JSON, serializado en BSON, con campos ordenados, tipos diversos y subestructuras anidadas. No hay un esquema fijo que obligue a todas las filas a compartir columnas, lo que admite heterogeneidad dentro de una misma colección.
Colecciones y clave
Los documentos se agrupan en colecciones, emparentadas con las tablas pero más laxas. Cada uno recibe un identificador único generado por el motor, con marca temporal, que sirve para enrutar y ordenar.
Embebido frente a referenciado
Puedes incrustar los datos relacionados dentro del documento o guardar solo referencias a otros. Se embebe cuando la relación es de uno a pocos y se leen juntos; se referencia cuando crece sin límite o se consulta suelta, para no inflar documentos ni duplicar.
Consultas
Se filtra por campos con operadores comparativos y lógicos, y se proyecta qué devolver. Los índices aceleran los filtros igual que en relacional, y se puede ordenar y limitar el resultado.
Agregación
El pipeline de agregación encadena etapas: selecciona documentos, los reorganiza con agrupaciones, desenvuelve listas y calcula métricas. Es el equivalente a un group by con extras, pero por etapas componibles.
Qué ganas y qué pierdes
- Ganas flexibilidad de esquema y lecturas de un solo disparo sobre datos cohesionados.
- Pierdes las garantías de integridad referencial y las uniones baratas entre colecciones.
- Ganas escalado horizontal sencillo a cambio de pensar el modelo al reescribirlo.
Atomicidad por documento
La escritura sobre un único documento es atómica, lo que hace muy cómodas las operaciones donde todo o nada afecta a una entidad. Cruzar documentos exige transacciones, más caras y no siempre disponibles.
Errores frecuentes
- Embeber relaciones que crecen sin límite, hasta reventar el tamaño del documento.
- Copiar el modelo relacional tabla por tabla en vez de pensar la consulta dominante.
- Olvidar los índices sobre los campos filtrados y pagar escaneos completos en cada lectura.
Ejemplo resuelto: modelar un catálogo de cursos
Una plataforma quiere mostrar la ficha de un curso con sus lecciones en una sola lectura. El diseño:
- Partir de la lectura dominante: ficha completa del curso, no consultas sueltas de lecciones.
- Embeber las lecciones dentro del documento del curso, pues son acotadas y se leen juntas.
- Referenciar en cambio profesores e inscripciones, entidades compartidas y con crecimiento propio.
- Indexar el slug del curso para que la ficha llegue sin escanear la colección.
¿Para qué sirve en la realidad?
Perfiles con preferencias, catálogos con variantes, eventos con listas de asistencia: todo dominio con entidades cohesionadas y esquemas que cambian encuentra en los documentos lecturas de un disparo y evolución de campos sin migraciones dolorosas.
Un artículo de blog admite comentarios y quieres leer el artículo con sus comentarios más recientes en una sola operación. La decisión de modelado más adecuada suele ser:
En una base de documentos todas las filas de una colección están obligadas a tener exactamente los mismos campos.
Documentos
Ordena las etapas típicas de un pipeline de agregación para un informe:
Filtrar
Reorganizar
Calcular
Presentar
Documentos en MongoDB
Guía oficial sobre la estructura de documentos, BSON y el modelado embebido frente a referenciado.
Une cada decisión de modelado con cuándo conviene.
Modela según la lectura
# Bases de documentos ## Documento ### JSON con anidados ### BSON ## Modelado ### embeber si se lee junto ### referenciar si crece ## Consulta ### filtros y proyección ### pipeline de agregación ## Límites ### sin uniones baratas ### transacciones costosas
Pipeline de agregación
Documentación oficial de las etapas para transformar y resumir colecciones de documentos.
Estás modelando una red social con seguidores potencialmente ilimitados por usuario. ¿Embebes la lista de seguidores o la referencias? Argumenta con tamaño de documento y patrón de lectura.