MongoDB es más flexible que un espagueti. No nos impone esquemas ni estructuras super definidas. Podemos ser tan desordenados como yo en mi cuarto y aun así MongoDB no nos dice nada. MongoDB es libertad y por esto mismo puede romperse igual de fácil que un espagueti.
Un gran poder conlleva una gran responsabilidad.
Nuestro orden y buenas prácticas determinan qué base de datos es mejor para nosotros. Si nos gusta el orden y la calma, si disfrutamos de planear y organizar la estructura de nuestras aplicaciones, entonces, solo entonces, podemos disfrutar de todos los superpoderes de MongoDB.
En cambio, si somos rebeldes, si trabajamos con afán y solo queremos ver el mundo arder, entonces le debemos nuestras vidas a las reglas de los esquemas y las estructuras ultra definidas de SQL. Tu decides.
Existen 4 tipos de bases de datos no relacionales:
Key Value Stores: Son super sencillas y muy rápidas. Guardan nuestra información en formato de llaves y valores: llave: valor. Son muy útiles para guardar caché y alguna información de sesión de los usuarios pero no podemos usarlas en casos más complejos donde necesitamos estructuras más especiales. El mejor ejemplo de estas bases de datos es Redis.
Graph Databases: Bases de datos basadas en Grafos. Los grafos son un tipo de datos donde todos los puntos de información pueden salir de cualquier parte y cada punto debe tener por lo menos una conexión con algún otro punto de información, es decir, otro grafo. Estas bases de datos nos ayudan a establecer conexiones entre nuestras entidades para realizar consultas de una forma más eficiente que en bases de datos relacionales. Ejemplos: Neo4j y JanusGraph.
Wide-column Stores: Son bases de datos columnares. Tienen una llave de fila y otra de columna para hacer consultas muy rápidas y guardar grandes cantidades de información. Pero, modelar los datos se puede volver un poco complicado. Podemos usarlas en Big Data, IoT, sistemas de recomendaciones, entre otras. Ejemplos: Cassandra y HBase.
Document Databases: Bases de datos basadas en documentos como MongoDB. Son muy flexibles y nos permiten guardar una gran cantidad de documentos (en vez de tablas) de forma distribuida.
MongoDB es una base de datos gratis y de código abierto. Pertenece al mundo no relacional (NoSQL) y nos permite guardar una gran cantidad de documentos (en vez de tablas) de forma distribuida.
Entre sus características podemos destacar que MongoDB es “Schema Less”: tiene una muy baja rigidez que nos permite construir nuestros documentos con estructuras diferentes sin afectar el funcionamiento de nuestras aplicaciones. Esto no lo podemos hacer con las tablas de las bases de datos relacionales 😏.
Antes de seguir debemos aclarar algunos términos de MongoDB para hablar en el mismo lenguaje:
Con MongoDB es muy fácil empezar nuestros desarrollos y añadir nuevas funcionalidades a medida que se nos van ocurriendo. Tenemos una gran flexibilidad para modelar o estructurar situaciones de la vida real gracias a la no rigidez de los documentos en formato BSON.
Además, ¿has escuchado de los documentos embebidos? Son documentos dentro de otros documentos. Nos ayudan a guardar nuestra información en un solo documento. Gracias a ellos evitamos consultar diferentes documentos y colecciones para obtener la información completa, en vez de solo por pedacitos.
No podemos simplemente usar MongoDB así no más. Como te dije, MongoDB nunca nos impide ser desordenados como yo en mi cuarto. Pero, por esto mismo, las malas prácticas con los documentos embebidos también pueden ser nuestra perdición.
Verás, una colección puede tener cientos de documentos con formatos diferentes y sin sentido ni relación entre sí. Por ejemplo: Una colección de animales puede tener diferentes documentos de animales, por supuesto. Pero, cada documento puede tener información diferente.
Algunos pueden incluir la especie de cada animal y algunos otros campos pero, al mismo tiempo, otros documentos puede que no incluyan esta información. Algunos pueden entender la edad como un número y otros pueden más bien guardar la fecha de nacimiento.
Entre más grande son nuestras aplicaciones, más espagueti se puede volver nuestra información. Vamos a necesitar muchas horas en el psicólogo solo por leer nuestros documentos para entender cómo escribir las consultas más básicas. Por ser demasiado fácil, terminó siendo demasiado complicado. Cuando todo se puede, todo puede salir muy muy muy mal.
El orden impuesto de SQL no es por nada. Aquí SQL tiene una enorme ventaja porque de ninguna manera nos permite este tipo de desorden. Si comparamos con MongoDB, desobedecer las reglas es mucho más complicado.
Las tablas son fáciles de entender. Las consultas pueden resultar relativamente obvias. Todo sigue su orden y tranquilidad. Aunque, por supuesto, nos tomara un buen tiempo implementar nuevas features.
No podemos añadir campos de prueba a solo una parte de nuestra base de datos. Por ejemplo, si queremos darle la opción a nuestros usuarios de seleccionar su color favorito, debemos seleccionar a ABSOLUTAMENTE TODOS nuestros usuarios de la base de datos y añadir el campo de color favorito con un valor por defecto.
Además, es necesario que creemos tablas diferentes para cada una de nuestras entidades. Siguiendo nuestro ejemplo, debemos separar a los animales de sus hábitats naturales (eso suena terrible) y unirlos por medio de referencias.
No es la mayor cosa pero ¡esto es terrible! Es como si SQL nos suplicara e hiciera todo lo posible para que no trabajemos en las nuevas características de nuestras aplicaciones.
En otras palabras: todo está muy bien separado y es muy fácil entender dónde están y cómo funcionan nuestras entidades. Pero (por ejemplo), si queremos la información completa de nuestros animales, debemos usar las referencias para hacer consultas compuestas a tablas diferentes dependiendo de qué tan compleja sea nuestra aplicación. En muchos casos esto resulta muy costoso.
Volvemos al mismo problema. Si no usamos buenas prácticas, vamos a tener un código espagueti imposible de entender.
Por el bien de tu psicólogo. Por amor a tu familia que te quiere mucho. Por amor a ti mismo o por lo que sea. Por favor, no trabajes con afán. No pienses que todo se resolverá mágicamente con el tiempo. Si no cuidamos nuestro trabajo vamos a pagar las consecuencias. ¡Nunca es tarde para volver al lado de la luz!
Desde el principio debemos pensar en el final. Podemos ahorrarnos muchos problemas si siempre pensamos cómo puede escalar nuestro trabajo puede escalar y cómo podemos optimizarlo.
Las buenas prácticas son como las buenas mamás. Siempre están encima regañando y tu estás harto de ellas. Te indican el camino correcto y te ayudan a caminar por él de la mejor forma posible. Pero, si las ignoras, van a dejar que te estrelles con la vida para que vuelvas a ellas y dejes tanta rebeldía.
Solo es una alegoría. No me hago responsable de que apliques mis consejos de programación a tu vida vida personal, mucho cuidado.
MongoDB nos permite toda la flexibilidad del mundo y la mejor forma de aprovechar todos estos beneficios es que nosotros mismos nos impongamos las reglas. Podemos pedir prestadas algunas buenas prácticas de SQL para ajustarlas un poco y sacar el mayor provecho de MongoDB.
Podemos usar tanto referencias como documentos embebidos para guardar la información de nuestras entidades. En muchos casos es mejor no abusar de los documentos embebidos y más bien separar nuestros documentos por colecciones dependiendo de las entidades que estamos manejando.
El objetivo de MongoDB NO es ser como SQL. Pero, aun así, debemos tener algunas conceptos muy claros. Por ejemplo: las relaciones, la forma en que nuestras entidades o documentos se encuentran enlazados unos con otros.
Retomando nuestro ejemplo de los animales, podemos juntar todo el poder de SQL y la flexibilidad de MongoDB para conseguir mejores resultados:
Te invito a tomar el Curso de MongoDB en Platzi. Vamos a aprender desde cero cómo funcionan las bases de datos no relacionales y cómo aprovechar todas las características de MongoDB para construir aplicaciones escalables y mantenibles al mismo tiempo.
No olvides que SQL sigue siendo muy importante. No tanto porque debamos usarlo (aunque, también), más bien, piensa en SQL como un estudio de las buenas prácticas que podemos traducir a MongoDB para obtener mejores resultados. Todo esto lo puedes aprender en el Curso de Fundamentos de Bases de Datos en Platzi 😉.
Por último y con mucho cariño, guarda este mensaje como una carta de tu mejor amigo: Di no a la rebeldía. Usa MongoDB con responsabilidad.
¡#NuncaParesDeAprender! 🤓💚
Otra comparación:
este link da error 404
Te lo comparto link.
¡Hola Juan David!
Muchas gracias por escribir este post. Soy nuevo en el mundo de la programacion y poco a poco voy sumergiendome en este campo, que hace poco me voy dando cuenta que tiene muchisima profundidad. A tal grado, que creo que las escuelas deberian darle su propia asignatura dentro del area de ciencia, tal como fisica, quimica y biologia.
Me gusta mucho que MongoDB te permita trabajar a tu estilo, y segun tu propio “orden”. Sin embargo concuerdo completamente con lo que dices de las buenas practicas. Hay que tener en consideracion que la mayoria del tiempo, leeremos codigo de otros programadores, e incluso nuestro propio codigo.
En conclusion, debemos programar de manera los suficentemente ordenada, para hacer eficiente la tarea de lectura para nuestros compañeros.
💪🤓
Hola,
El asunto del SQL “vs” NoSQL (no es “no relacional” sino “Not Only SQL”) tiende a ser como “Windows vs Linux” y eso es algo que bajo ningún rol se debería ver como mundos contrarios, aparte y en guerra.
SQL cumple aún con aspectos muy importantes que el mundo NoSQL aún no, ACID e integridad de datos, por ejemplo.
La preferencia de uso y la integración entre ellos se da dependiendo del contexto específico. En algunos casos es vital la consistencia, en otros se puede flexibilizar en pro de otros factores.
Finalmente, no se debería contemplar el mundo NoSQL como “la solución al tedio SQL” sino sencillamente conocer bastante bien las herramientas para usarlas adecuadamente y no sólo adaptar prácticas de uno a otro. De lo contrario sería como sugerir que en un taller puedes usar una llave de tubo como martillo para no “cargar con el martillo”.
Saludos!
Muy buen artículo Juan David, creo que voy a utilizar Mongo para unos casos muy puntuales donde no requiera querys de multiples relaciones y donde el costo sea bajo pero me inclino mas por las bases relacionales tengo varios proyectos en producción y trato de visualizarlos en Mongo y la verdad que despelote.
Soy cosmosoftroot del futuro y ahora trabajo con Mongo y vengo a contarles que estaba un poco prevenido al principio pero hoy en día trabajo con esta tecnología y esta genial para bases de datos que requieran mutar sus estructuras de datos y que permitan un crecimiento elástico en función de la demanda.
Sigues usando la mezcla entre SQL y NoSql? Si es así, puedes darnos tu punto de vista de como te ha ido? 😃
También vengo del futuro a decirte que mongoDB no es opensource (ni gratis)
https://en.wikipedia.org/wiki/Server_Side_Public_License
Vengo del futuro y te pido por favor que primero tomes el curso de Flask o sufriras lagrimas de sangre.
Muchas gracias por tu post.
Ahora entiendo mejor el concepto NoSQL
Una vez termine el curso que estoy realizando me iré a estudiar más sobre este mundo desconocido para mí.
Excelente articulo y justo a tiempo, me encuentro diseñando una plataforma iot y esto me cae como anillo al dedo.
Gracias por tomarte el tiempo de Escribirlo!!!
Hola Juan, buen dia. Soy Desarrollador de Software y tmb doy clases de datos en un Terciario de Bases de Datos… Cuesta mucho desprender a los estudiantes jovenes de la idea que SQL es el pasado y las NoSQL son el futuro y su reemplazo… en cuanto a sistemas transaccionales, es mejor mantener la estructura de E-R para salvaguarda de los datos, y es aquí donde los docentes tratamos de hacer hincapié…
Muy buen post, con tu permiso, me lo puedo llevar? para mostrar a los estudiantes que no son sólo sus profes los que piensan así XD. Saludos!
¡Claro! Siempre que menciones que yo lo escribí todo va bien. La información es de todos 🤔😉.
Excelente!. Ni más ni menos. MongoDB bien usado permite degustar una buena pasta!.
Estas de acuerdo con la opinión de que para una startup donde se necesita hacer las cosas mas rapido de lo normal y hay que ir diseñando sobre la marcha es mejor usar mongodb a una base relacional porque nos permite ir diseñando sobre la marcha y si se comete un error se arregla en la marcha en vez de tener un plan super estructurado antes de empezar a programar una base sql, que base prefieres para una startup ? es un disparate lo que digo ?
qué base de datos es recomendable usar para una aplicación de contact Centre?
Se necesitaría mas información para poder sugerir algo.
Muy bueno el post! gracias por las recomendaciones 😄
Buen post, aunque esperaba indicaras por ejemplo los 10 puntos a considerar para armar una buena base de datos y colecciones. Entiendo los puntos mencionados, pero esperaba un poquito mas. Aun asi me gusto y lo lei hasta le final. Tomare el curso. Slds !!
@cosmosoftroot @albertusortiz deberiamos hacer una fiesta de viajeros del tiempo por alla en el 2010 y reunirnos a minar bitcoins.
Si estan deacuerdo dejenme un mensaje en cristalab o en maestrosdelweb en el 2009 😎