¿Por qué nunca deberías usar el bloc de notas para representar una matriz para un videojuego 3D?
¿Qué tiene que ver MongoDB, MySQL o Neo4j -por citar una de grafos- con la incapacidad de un equipo de programadores para diseñar la arquitectura correcta? Porque ese parece el problema.
Las aplicaciones sociales necesitan sistemas híbridos de almacenamiento y recuperación porque, en efecto, puede convenir almacenar por dupli o triplicado para después extraer y analizar datos como más convenga: de forma documental al estilo NoSQL, de forma documental indexada (relacional y/o NoSQL), de forma relacional estándar (de toda la vida de dio$), o desde un motor de almacenamiento específico para la resolución y recorrido de grafos.
Ninguna de ellas es correcta en términos absolutos, como se puede intuir en el artículo más allá de su titular sensacionalista; pero no me imagino arrancando el artículo con un: ¿Por qué nunca deberías usar Oracle...?
#2 No es sensacionalista. En mi caso específico, llevo 18 meses desarrollando sobre MongoDB (después de un chorrón de años de utilizar PostgreSQL) y no puedo estar más de acuerdo con el autor del artículo.
El fondo del artículo es que últimamente hay una tendencia a pretender utilizar MongoDB como una base de datos de propósito general para sustituir las tradicionales BBDD relacionales en entornos web, y en mi opinión es una postura totalmente equivocada.
MongoDB tiene algunas cosas geniales (sharding, schemaless, un gran rendimiento), pero está pensada para Big Data y para poder obtener los rendimientos que obtiene, sacrifica algunas de las cosas que damos por supuestas en una base de datos como la capacidad de hacer un join de tres tablas para sacar resultados agregados.
Si tu aplicación está muy orientada a documentos independientes y lo tienes muy muy claro pues genial, utiliza MongoDB y cuando necesites relacionar datos utiliza algunas de las estrategias alternativas (salir del paso utilizando el aggregation framework / Map Reduce, realizar join en memoria - consumo de RAM - o join en el código - leeeento y con consumo de CPU -, cachear resultados en redis o memcached, etc.).
Pero si no lo está o no lo tienes claro, mejor utilizar una BBDD relacional de "las de toda la vida", porque a la que una aplicación resulte medianamente interesante por lo general crece hasta un punto en que necesitas relacionar datos de unas tablas/colecciones con otras y en este caso pierdes todo el tiempo (y más) que hubieras podido ganar al utilizar MongoDB al principio, y depende como te puedes encontrar con algun escollo insalvable.
En cualquier caso me parece que este hilo estaría mejor en Stack Overflow que en Menéame
#3 Sigue siendo sensacionalista. Para no serlo debería titularse: ¿Cuándo no debes usar NoSQL?
Podrías usar PostgreSQL como sistema NoSQL. El error será el paradigma escogido, no la herramienta. Recordemos que el NoSQL ya existía antes de que una panda de gafapastas del teclado lo convirtieran en moda. ¿Te parecería bien, como dije antes, que esto se titulara "Por qué no deberías usar PostgreSQL"?
Es otra de las cosas que hacen sospechar del artículo: se debería hablar de NoSQL y no particularizar en MongoDB. Lo contrario indica una visión muy limitada, muy de fanboy o hypero de temporada. Es otros de los signos de esta época: convertir un caso particular en metonimia y/o sinécdoque de un mundo mucho más complejo.
Que la gente use MongoDB como DB de propósito general es un error de esa misma gente, no de la concepción de la herramienta. Es la incapacidad para separar programación en bruto de análisis y arquitectura. Mi conclusión de este artículo es: hay que estudiar más y hablar menos.
Hace unos años podías elegir entre un RDBMS y otro RDBMS. No había más, por desconocimiento o por cerrazón. Ahora la gente empieza a abrir su mente a otro paradigma y empiezan los problemas: hay que hacerse de una cosa o de la otra por fanboyerismo. Debería ser todo más fácil, pero no; la elección nos abre una puerta al abismo.
El desarrollo moderno se basa en la agregación -en serie o en paralelo- de diferentes tecnologías. Las herramientas no son unitarias, son sistemas de arquitectura modular1. Ya no se puede escoger sin miedo al error. Tú mismo lo dices: "si no lo tienes claro"... ¡Pero es que siempre hay que tenerlo claro!
(1) Me ha venido a la cabeza una herramienta de backend que desarrollé hace un par de años: usaba indistintamente un RDBMS y un NoSQL, por separado o conjuntamente. Era el desarrollador el que elegía -o incluso combinaba- según el uso requerido. Claro que la lógica relacional era poco eficiente en el NoSQL (aunque podían delegarse los índices al DB convencional). Seguro que los que trabajan en la herramienta habrán metido la pata al diseñar ciertos usos como NoSQL, pero es su carencia, no la mía.
Comentarios
Pero nunca, ¿nunca?
Sensacionalista.
¿Por qué nunca deberías usar el bloc de notas para representar una matriz para un videojuego 3D?
¿Qué tiene que ver MongoDB, MySQL o Neo4j -por citar una de grafos- con la incapacidad de un equipo de programadores para diseñar la arquitectura correcta? Porque ese parece el problema.
Las aplicaciones sociales necesitan sistemas híbridos de almacenamiento y recuperación porque, en efecto, puede convenir almacenar por dupli o triplicado para después extraer y analizar datos como más convenga: de forma documental al estilo NoSQL, de forma documental indexada (relacional y/o NoSQL), de forma relacional estándar (de toda la vida de dio$), o desde un motor de almacenamiento específico para la resolución y recorrido de grafos.
Ninguna de ellas es correcta en términos absolutos, como se puede intuir en el artículo más allá de su titular sensacionalista; pero no me imagino arrancando el artículo con un: ¿Por qué nunca deberías usar Oracle...?
Rubbysh.
#2 No es sensacionalista. En mi caso específico, llevo 18 meses desarrollando sobre MongoDB (después de un chorrón de años de utilizar PostgreSQL) y no puedo estar más de acuerdo con el autor del artículo.
El fondo del artículo es que últimamente hay una tendencia a pretender utilizar MongoDB como una base de datos de propósito general para sustituir las tradicionales BBDD relacionales en entornos web, y en mi opinión es una postura totalmente equivocada.
MongoDB tiene algunas cosas geniales (sharding, schemaless, un gran rendimiento), pero está pensada para Big Data y para poder obtener los rendimientos que obtiene, sacrifica algunas de las cosas que damos por supuestas en una base de datos como la capacidad de hacer un join de tres tablas para sacar resultados agregados.
Si tu aplicación está muy orientada a documentos independientes y lo tienes muy muy claro pues genial, utiliza MongoDB y cuando necesites relacionar datos utiliza algunas de las estrategias alternativas (salir del paso utilizando el aggregation framework / Map Reduce, realizar join en memoria - consumo de RAM - o join en el código - leeeento y con consumo de CPU -, cachear resultados en redis o memcached, etc.).
Pero si no lo está o no lo tienes claro, mejor utilizar una BBDD relacional de "las de toda la vida", porque a la que una aplicación resulte medianamente interesante por lo general crece hasta un punto en que necesitas relacionar datos de unas tablas/colecciones con otras y en este caso pierdes todo el tiempo (y más) que hubieras podido ganar al utilizar MongoDB al principio, y depende como te puedes encontrar con algun escollo insalvable.
En cualquier caso me parece que este hilo estaría mejor en Stack Overflow que en Menéame
#3 Menéame ya no es lo que era.
#3 Sigue siendo sensacionalista. Para no serlo debería titularse: ¿Cuándo no debes usar NoSQL?
Podrías usar PostgreSQL como sistema NoSQL. El error será el paradigma escogido, no la herramienta. Recordemos que el NoSQL ya existía antes de que una panda de gafapastas del teclado lo convirtieran en moda. ¿Te parecería bien, como dije antes, que esto se titulara "Por qué no deberías usar PostgreSQL"?
Es otra de las cosas que hacen sospechar del artículo: se debería hablar de NoSQL y no particularizar en MongoDB. Lo contrario indica una visión muy limitada, muy de fanboy o hypero de temporada. Es otros de los signos de esta época: convertir un caso particular en metonimia y/o sinécdoque de un mundo mucho más complejo.
Que la gente use MongoDB como DB de propósito general es un error de esa misma gente, no de la concepción de la herramienta. Es la incapacidad para separar programación en bruto de análisis y arquitectura. Mi conclusión de este artículo es: hay que estudiar más y hablar menos.
Hace unos años podías elegir entre un RDBMS y otro RDBMS. No había más, por desconocimiento o por cerrazón. Ahora la gente empieza a abrir su mente a otro paradigma y empiezan los problemas: hay que hacerse de una cosa o de la otra por fanboyerismo. Debería ser todo más fácil, pero no; la elección nos abre una puerta al abismo.
El desarrollo moderno se basa en la agregación -en serie o en paralelo- de diferentes tecnologías. Las herramientas no son unitarias, son sistemas de arquitectura modular1. Ya no se puede escoger sin miedo al error. Tú mismo lo dices: "si no lo tienes claro"... ¡Pero es que siempre hay que tenerlo claro!
(1) Me ha venido a la cabeza una herramienta de backend que desarrollé hace un par de años: usaba indistintamente un RDBMS y un NoSQL, por separado o conjuntamente. Era el desarrollador el que elegía -o incluso combinaba- según el uso requerido. Claro que la lógica relacional era poco eficiente en el NoSQL (aunque podían delegarse los índices al DB convencional). Seguro que los que trabajan en la herramienta habrán metido la pata al diseñar ciertos usos como NoSQL, pero es su carencia, no la mía.
Lectura de la noche, sin duda.