MongoDB en Platzi: bases de datos NoSQL para datos que no caben en filas y columnas

SQL me sirvió durante años para todo. Hasta que trabajé en un proyecto con datos de estructura variable — cada registro podía tener campos distintos — y el modelo relacional se convirtió en un obstáculo.

MongoDB resuelve ese problema. El curso de Platzi enseña cuándo es la solución correcta.

El modelo de documentos y por qué cambia las cosas

En MongoDB no hay filas y columnas — hay documentos JSON. Cada documento puede tener su propia estructura. Eso elimina la necesidad de tablas de junction, JOINs complejos y esquemas rígidos para datos que naturalmente no son tabulares.

Un catálogo de productos donde cada producto tiene atributos diferentes (un celular tiene RAM y cámara, una camisa tiene talla y material) encaja naturalmente en documentos. En SQL requeriría un esquema de atributos genérico o tablas separadas por categoría.

Cuándo lo usamos y cuándo preferimos SQL

Para datos con relaciones fuertes y transacciones ACID — inventario, facturación, contabilidad — SQL sigue siendo la elección correcta. Para datos de estructura variable, logs, configuraciones por usuario o contenido CMS — MongoDB hace el trabajo más limpio.

En los proyectos del portafolio, MongoDB aparece en plataformas de contenido y sistemas con datos heterogéneos. Los sistemas transaccionales siguen usando PostgreSQL o MySQL. La elección depende del caso, no de la preferencia.

Lo que el curso de Platzi enseña bien

El diseño de esquemas en MongoDB — aunque no hay esquema forzado, el diseño importa. La regla de oro: datos que se acceden juntos, se guardan juntos. Eso es lo opuesto a la normalización de SQL y requiere un cambio de modelo mental.

Las operaciones de agregación — el pipeline de MongoDB para transformar y analizar datos — son poderosas pero tienen curva de entrada. El curso las cubre con ejemplos reales. Si querés hablar de bases de datos para tu proyecto, escribínos.