Diseñar un schema en MongoDB significa definir la estructura, los tipos, las reglas de evolución y las convenciones que deben respetar los documentos de una colección. La flexibilidad de MongoDB permite introducir cambios gradualmente, pero no elimina el schema: solo permite que parte de él sea implícito si el equipo no lo gobierna.
dominio y access patterns
↓
document boundary
↓
campos, tipos y invariantes
↓
convenciones y versionado
↓
validation, índices y migraciones
El schema no debe diseñarse aislado de queries y comandos. Un campo puede ser correcto desde el dominio, pero estar ubicado de una manera que dificulte atomicidad, crecimiento o indexación.
MongoDB Server no completa automáticamente cualquier campo ausente por el simple hecho de que el schema lo documente.
Ejemplo de default de lectura:
TypeScript
const status = document.status ??'pending';
Esto puede mantener compatibilidad durante una migración, pero no debe ocultar indefinidamente documentos mal formados. Después del backfill se puede endurecer validation.
No todos los documentos necesitan todos. Define qué eventos requieren auditoría y si los datos pueden confiarse a la aplicación.
updatedAt debe cambiar en cada modificación relevante. Si existen múltiples caminos de escritura, la consistencia puede protegerse en repositorios, ODM middleware o update pipelines, pero debe probarse.
Todo array debe tener una política de crecimiento.
JavaScript
{items:[/* máximo definido por la orden */]}
Documenta:
cardinalidad esperada y máxima;
si permite duplicados;
si el orden importa;
cómo se actualiza;
si se indexa;
qué ocurre con outliers.
No utilices $addToSet como sustituto universal de unicidad. En arrays de documentos, la igualdad considera el valor completo y no protege una clave interna como lo haría un índice unique en otra colección.
Debe existir un discriminador y reglas por variante. Si los tipos tienen lifecycle, índices y queries totalmente diferentes, colecciones separadas pueden ser más claras.
El primero sirve un listado. El segundo protege unicidad por tenant. Crear índices sin asociarlos a queries o reglas produce deuda y coste de escritura.
Schema flexible significa evolución controlada, no ausencia de diseño. Un schema completo conecta estructura, tipos, lifecycle, índices, validación y migraciones. Su calidad se mide por cuánto reduce ambigüedad sin impedir que el sistema evolucione.
Comprueba lo aprendido
¿Por qué BSON válido no implica documento válido para el dominio?
¿Qué diferencia existe entre required, optional y condicional?
¿Cómo introducirías un campo nuevo requerido sin romper documentos antiguos?
¿Qué problemas aparecen al usar el mismo tipo para input y persistencia?
¿Cómo afecta soft delete a queries e índices unique?
¿Qué información debe acompañar a cada array del schema?