Validar datos en MongoDB no se limita a tipos primitivos como string, number o boolean. Cuando trabajas con documentos reales, te encuentras con arrays anidados y subdocumentos que también requieren reglas claras para mantener la integridad de la información. Aquí aprendes a usar JSON Schema para validar estructuras complejas dentro de una colección NoSQL.

¿Cómo validar un array dentro de un documento en MongoDB?

Cuando un campo guarda varios valores, como las tallas de una camiseta, el tipo de dato deja de ser primitivo y pasa a ser un array. Para validarlo, defines el bsonType como array y luego describes qué reglas deben cumplir sus elementos.

Dentro de la colección products, imagina un campo sizes que almacena las tallas disponibles. La validación empieza así:

• bsonType: array para indicar que el campo debe ser una lista.
• items para describir el tipo de cada elemento, en este caso string.
• uniqueItems: true para evitar valores duplicados como dos veces la talla L.
• minItems: 1 para asegurar que, si se envía el array, tenga al menos un elemento.

¿Qué hace uniqueItems en JSON Schema? Obliga a que todos los valores dentro del array sean diferentes. Si intentas insertar ["L", "XL", "L"], la validación falla porque la L se repite [02:54].

Con estas reglas, el campo sizes es opcional, pero si llega vacío o con duplicados, MongoDB rechaza el documento. Así proteges la coherencia sin perder flexibilidad.

¿Por qué usar enum o string en items?

Usar enum limita los valores a una lista cerrada, por ejemplo solo S, M, L, XL. Es útil cuando manejas categorías muy controladas. Sin embargo, si la colección guarda productos diversos que no siempre se miden en tallas de ropa, conviene dejar string para mantener la reutilización del esquema.

Esta decisión es clave en bases NoSQL: defines suficiente estructura para cuidar la integridad, pero dejas margen para que el modelo crezca.

¿Cómo validar un subdocumento en MongoDB con JSON Schema?

Un subdocumento es un objeto anidado dentro de otro documento. En el ejemplo, cada producto tiene una category con su propio name e image. Para validarlo, anidas un nuevo JSON Schema dentro de la propiedad.

La estructura sigue este patrón:

• El campo category se declara con bsonType: object.
• Dentro defines properties para describir cada atributo del subdocumento.
• Marcas name como required y dejas image como opcional.
• Cada propiedad interna también lleva su propio bsonType, normalmente string.

¿Qué pasa si falta un campo requerido en un subdocumento? MongoDB rechaza el insert completo. Si envías una categoría sin name, aunque el resto del producto sea válido, la operación falla [07:30].

Esta capacidad de anidar esquemas dentro de esquemas es lo que permite trabajar con modelos ricos sin perder control. Cada nivel del documento puede tener sus propias reglas, tipos y campos obligatorios.

¿Cómo aplicar los cambios en una colección existente?

Cuando modificas un validador, necesitas hacer drop de la colección y volver a crearla con el nuevo JSON Schema. Ten en cuenta que esto borra los documentos existentes, así que en producción usarías collMod para actualizar el validador sin perder datos.

Después de recrear la colección, prueba estos casos para confirmar que las reglas funcionan:

1. Insertar un producto solo con name y sin sizes: debe pasar, porque el array es opcional.
2. Insertar un producto con sizes: []: debe fallar por minItems: 1.
3. Insertar un producto con sizes: ["L", "L"]: debe fallar por uniqueItems.
4. Insertar un producto con category sin name: debe fallar por campo requerido.
5. Insertar un producto válido con name, sizes: ["XL"] y category completa: debe crearse sin problema.

¿Qué reglas adicionales puedes aplicar a arrays y objetos?

Más allá de los ejemplos básicos, JSON Schema ofrece varias palancas para afinar la validación. Estas son las que más usarás en colecciones reales:

• minItems y maxItems para controlar el tamaño del array.
• uniqueItems para evitar duplicados dentro de la lista.
• items con un esquema completo, no solo un tipo, para validar objetos dentro del array.
• required dentro de un subdocumento para marcar campos obligatorios al nivel correcto.
• additionalProperties: false para impedir que se envíen campos no declarados.

La combinación de estas reglas convierte a MongoDB en una base flexible pero gobernada. Mantienes la libertad del modelo NoSQL y, al mismo tiempo, defines estándares claros que protegen tu información.

Un reto interesante para practicar es validar un campo password con expresiones regulares, exigiendo mínimo de caracteres, números y letras. ¿Cómo lo resolverías tú? Cuéntame en los comentarios qué reglas aplicarías y qué patrón usarías.