NoSQL: No es oro todo lo que reluce

NoSQL, o tal vez sí?

Muy buenas! Seguro que más de uno ha oído hablar de las bondades de las bases de datos llamadas “nosql”. Yo también y la verdad es que me intrigaba mucho así que me puse a analizarlo fríamente. Todos los benchmarks y comentarios de la gente dan como absoluto ganadador a las “nosql”, obligando al destierro a las bases de datos relacionales. Después de analizar qué es cada cosa y las necesidades reales he llegado a una conclusión: Nada más lejos de la realidad. Intentaré explicar lo mejor posible mis razonamientos, quizá de manera demasiado abstracta, del por qué las “nosql” no son la panacea. No obstante, esto es mi opinión y alguien puede pensar que sólo digo chorradas o que en algún aspecto estoy totalmente confundido. Si es así, me gustaría saberlo ya que mi intención siempre es aprender más y nunca imponer mis ideas. Pero siempre desde el respeto 😉Lo primero de todo y de las cosas que más rabia me da es que la mayoría de los benchmarks (muchos son más bien pruebecillas que hace alguien en 10 minutos) miden sólo el tiempo que tarda en leer n entradas o en insertar otras tantas. Bien, ahí la verdad es que las nosql son muy rápidas pero pensemos un poco: ¿qué base de datos se centra exclusivamente en esas tareas? Muy pocas y en casos muy concretos. Normalmente obtener información no es simplemente meter la mano en un cubo y sacarla sino que es algo más complejo. Esta complejidad  se trata de abordar mediante lo que las bases de datos relacionales llaman relaciones.

Por ejemplo, tengo una base de datos en la cual quiero saber cuanta gente es de cada país. Con una sóla consulta sql lo tengo mientras que con una nosql tengo que hacer, el mejor de los casos, tantas consultas como países haya. Ahora dime cuanto tiempo has tardado en hacer todas las consultas. A eso hay que sumarle que estás acoplando tu base de datos a la aplicación, ya que será la aplicación quien mediante funciones propias recorrerá y hará las tareas pertinentes (con su pérdida de eficiencia). Otro factor muy importante son las técnicas y estrategias con las que cuenta un sgbd relacional. Mediante estas técnicas es capaz de acelerar las consultas ya que, como sabe lo que quieres, trata de conseguirlo de la mejor manera posible.  Estas estrategias de optimización son imposibles en una nosql, ejecutarás todas y cada una de las consultas. De esta manera el tiempo total crecerá (en los mejores casos) de manera lineal frente al número de entradas mientras que en una relacional el crecimiento sería bastante más logarítmico.

Cojunto de SGBD Relacionales

Cojunto de SGBD Relacionales, los hay de todos los colores. Aunque si sabes SQL podrás manejarte con cualquiera de ellos.

Al usar una nosql estamos renunciando a un montón de funcionalidades. Todo aquel que haya trabajado a un nivel un poco avanzado con bases de datos relacionales será consciente de que hacer una consulta SQL tiene por qué se trivial: cuentas con un montón de posibilidades y hay que encontrar la mejor. Tenemos joins (unir tablas en base a relaciones entre ellas), conjuntos de datos (group by), un completo manejo de fechas (intervalos, sumas, restas, comparaciones…), integridad de los datos, transacciones, excepciones… un sin fin de posibilidades. Tarde o temprano te tocará hacer algo más que leer y escribir datos, y esa tarea la tendrá que hacer tu aplicación (java, php…). En ese momento, justo en ese momento la eficiencia de tu programa caerá por los suelos y todos los milisegundos que has creído ganar te están saliendo caros. Muy caros. Imagina una web donde quieras consultar un trayecto para un día concreto, a unas determinadas horas y que el tren (o lo que sea) pase por unas determinadas estaciones. Hacerlo con una nosql sería realmente doloroso y totalmente inviable.

También existen detalles más concretos como el que voy a comentar. Las nosql no proporcionan ninguna garantía ACID. Por decirlo de manera simple, un sistema ACID cuando dice que un dato se ha guardado, se ha guardado. Ya pueden pasar cualquier cosa que no vas a perder esa información. En cambio, las nosql te pueden decir que ya han guardado el dato pero todavía lo tienen por ahí en memoria de manera temporal y si en ese momento pasa algo “extraño” (se va la luz y el ordenador para, por ejemplo) el dato puede que no se haya guardado (aunque tu pienses que si porque te lo ha “asegurado”) y en ese caso habrás perdido ese dato para siempre. Alguno pensará que esto es una chuminada pero ya me dirás que pasa si surge algún problema de este tipo cuando te ingresen la nómina 😉

Otro tema realmente importante es la integridad de los datos. Esto viene a ser que la información que hay en la base de datos sea útil y verídica. Por ponernos en situación, imagina que tienes una base de datos con autores y libros que han escrito.  En un determinado momento, borras a un autor pero sus libros quedan en la base de datos. ¿A quién pertenecerán ahora esos libros? Tenemos datos que no nos son útiles, sabemos que existen pero… hay muchas lagunas. Otro caso parecido es intentar meter un libro sin indicar su autor. Podemos exigir que todo libro tenga su autor a la hora de insertarlos pero nada nos permitiría saltarnos esta “restricción” en una nosql. Todo esto queda delegado a la aplicación, con todos los inconvenientes que trae. Una buena base de datos es aquella que vela por su integridad. Si unos datos no son fiables, esa información no vale nada. Los datos lo son todo en una base de datos.

Por supuesto no estoy diciendo que las nosql son algo que se debería quemar o guardar en un cajón ni mucho menos. Se diseñaron con un objetivo en mente y la verdad es que lo cumplen muy bien. Este objetivo es el que dije al principio y es insertar muchos datos y acceder a ellos muy rápido, y estos datos no deben ser complejos. Facebook o Twitter dicen que utilizan Cassandra (una base de datos tipo “nosql”) y es normal, ahora te explico. Twitter consiste en insertar mensajes y ver los últimos. Por así decirlo, vas metiendo en un cubo cientos de mensajes y lo único que haces es “ver” los que están por encima. Este es un caso donde una nosql sería lo óptimo. No hay relaciones complejas y el orden viene definido por el orden de inserción (recordemos que ordenar es de las tareas más duras en informática). En Facebook es algo diferente. No puedo decirlo a ciencia cierta, pero aseguraría que no usan (ni tienen pensado hacerlo) una nosql para toda su base de datos. Los casos ideales es en sitios como el muro o comentarios de fotos. El motivo es lo mismo que en caso de twitter. Para el resto, no me cabe la menor duda de que usan algun tipo de base de datos relacional.

SGBD "nosql"

Son bastantes diferentes entre sí pero genéricamente se les puede llamar "nosql"

Tarde o temprano se hace alguna relación entre los datos y si esa relación la gestiona el SGBD mucho mejor que manejarlo nosotros a mano. Sinceramente, no me imagino a Facebook haciendo 3 o 4 consultas y luego desde php comprobar las coincidencias para buscar “amigos en común” (de listas enormes). O la alternativa, que sería un trabajo mínimo en php pero una cantidad de consultas exponencial (ambas opciones son totalmente inviables). La única opción donde tendría alguna posibilidad es mediante de la redundancia de datos. Pero la redundancia sería tal que el tamaño de la base de datos sería monstruoso, y toda la velocidad que ganas por ser más rápida podrías perderla por la “distancia” tan grande que tocaría recorrer.

Sin embargo, todas estas limitaciones de las nosql tienen otras ventajas (además de la velocidad). Estas bases de datos son excelentes para sistemas distribuidos y ahora que todo tiende a ponerse “en la nube” se pueden aprovechar desde ese punto de vista. Eso es lo que hace que google ofrezca BigTable en AppEngine (un servicio de hosting). Sin despeintarte puedes tener funcionando un sistema distribuido en tantos nodos como quieras. Esta tarea es bastante más compljea en una db relacional, precisamente por el tema de las relaciones.

Podría simplificar todo esto en una frase: La diferencia entre una db relacional y una nosql es como aquel que le quita los asientos a su coche para que corra más. Correrá más, pero pierdes prestaciones.

Aunque más bien lo relacionaría las churras y las merinas. Se parecen pero son muy diferentes. Pues lo mismo con db relacionales y “nosql”, las dos “guardan datos” pero su finalidad es muy diferente. Y como siempre, queda a criterio del diseñador usar una herramienta u otra (o las dos a la vez).

Para terminar, muchos pensarán que he escogido ejemplos concretos para intentar “machacar” a las nosql. Es cierto, y el motivo es para dar a entender que una base de datos nosql no puede sutituir a una base de datos relacional si lo que tenemos son datos altamente relacionados entre sí. No existen productos milagrosos, todo tiene sus contras. No existe (ni existirá) un sistema gestor de bases de datos (ni ningún software ni cosa en el mundo) que se comporte a la perfección en cualquier situación.

Un saludo y espero que alguien esté es desacuerdo, para así debatir y enriquecer el post un poco 😉

You may also like...

30 Responses

  1. MArioL dice:

    Desde ése punto de vista entonces queda claro para que sirve cada caso y cuando deberemos utilizarlo, muy bueno!!!

  2. carlos dice:

    muy bueno el artículo : )

    Lo que no acabo de entender es porqué tanto revuelo con esto del nosql, si esencialmente vendría a ser como trabajar con ficheros independientes, no?? y eso se hacía antes de los sgbd relacionales..

    salut!

  3. Maxpowel dice:

    Me alegro que os haya sido de utilidad 😉

    Carlos, es cierto que de manera abastracta se parece a trabajar con archivos (de hecho a las “tablas” en nosql se las llama Documentos) pero de manera infinitamente más rápida y distribuida (disponer de varios servidores).

  4. Fabio dice:

    “””Por ejemplo, tengo una base de datos en la cual quiero saber cuanta gente es de cada país. Con una sóla consulta sql lo tengo mientras que con una nosql tengo que hacer, el mejor de los casos, tantas consultas como países haya.”””

    Creo que estas equivocado, ¿como seria tu consulta?

  5. Maxpowel dice:

    Hola Fabio, quizá debí haber indicado la consulta en el propio post.
    Te digo cómo lo haría.
    Tengo dos tablas, una con los países y otra con los usuarios. La tabla países tiene dos columnas:
    id_pais que es la clave primaria de la tabla
    nombre_pais que es un texto único (unique)
    CREATE TABLE paises (
    id_pais INT PRIMARY KEY,
    nombre_pais VARCHAR(20) UNIQUE
    )

    La tabla usuarios puede tener más columnas pero en este caso lo reduciré a tres:
    id_usuario es la clave primaria
    usuario es un texto guarda el nombre de usuario
    id_pais contiene el id del pais y la usaremos para unir
    ambas tablas.

    CREATE TABLE usuarios (
    id_usuario INT PRIMARY KEY,
    usuario VARCHAR(20) UNIQUE NOT NULL,
    id_pais INT NOT NULL
    )

    Y ahora definimos la clave externa
    ALTER TABLE usuarios ADD FOREIGN KEY (id_pais) REFERENCES paises (id_pais)

    Ahora ya tenemos el esquema así que vamos a meter unos datos de prueba.
    Vamos a tener los paises España, Francia y Portugal y meteremos a los usuarios español1, español2, español3, frances1, frances2 y portuges1.

    Metemos los países
    INSERT INTO paises (id_pais, nombre_pais) VALUES (1,
    ‘España’),(2,’Francia’),(3,’Portugal’);

    Y ahora los usuarios
    INSERT INTO usuarios (id_usuario,usuario,id_pais) VALUES (1,’español1′,1),(2,’español2′,1),(3,’español3′,1),(4,’frances1′,2),(5,’frances2′,2),(6,’portuges1′,3);

    Después de todo esto ya podemos hacer la consulta para sacar todos los países y el número de usuarios de cada país

    SELECT count(*),nombre_pais FROM paises
    JOIN usuarios USING (id_pais)
    GROUP BY nombre_pais

    Esta consulta nos devolverá las siguiente filas
    cantidad de usuarios, pais
    3,España
    2,Francia
    1,Portugal

    Puedes probar insertando más usuarios y países.

    Si te interesa, escribí un artículo concretamente sobre esto
    http://www.congdegnu.es/2009/04/29/conoce-sql-select-parte-3-agrupaciones/

    Si tienes cualquier otra duda aquí estaré 😉

    Un saludo

  6. Jaime dice:

    Excelente articulo.

  7. EtnasSoft dice:

    Hola;
    he leído tú artículo de arriba a abajo y creo que hay varias cosas que matizar sobre las NoSQL.

    En primer lugar, estás comparando las bases de datos relaciones con el paradigma NoSQL y eso, ya de entrada, no es la mejor fórmula para aproximarse a estas últimas: la NoSQL no se han construído con el fin de rivalizar en cuanto a rendimiento, integridad, escalabilidad, etc, sino que vienen a ofrecer una funcionalidad que las relacionales, por definición, no pueden soportar.

    Y ahí es donde veo el mayor problema en tú artículo: no se trata de que en NoSQL montar una consulta con múltiples tablas involucradas sea mucho más complejo que en el sistema tradicional, sino que tenemos que pensar en un sistema que permite ‘otras’ cosas.

    Por ejemplo, para una aplicación tipo Wikipedia, la NoSQL resulta extremadamente más funcional que el sistema clásico: por cada entrada-fichero en NoSQL, podemos almacenar todas las revisiones por las que pasa un texto, con una velocidad de acceso y una capacidad de indexación y creación de índices superior a un SGBD como MySQL u Oracle. Además cuenta con replicación bidireccional y una capacidad de escalado extraordinaria. Los propios datos no estarían sujetos a determinados campos fijos en un esquema relacional, sino que serían de tipo orgánico según lo requirieran las circunstancias.

    Todo lo anterior, también lo hace el sistema tradicional; de hecho, es así. Pero para ese caso, un sistema NoSQL resultaría más interesante, de ahí que por ejemplo, el propio equipo de desarrollo de Wikipedia, Twitter y Foursquare se hayan planteado en mayor o menor medida la migración de sus servicios a estos sistemas.

    Para no hacer muy larga la respuesta, la conclusión a la que quiero llegar es que no es correcto comparar directamente las funcionalidades de un sistema con el otro porque no son herramientas excluyentes. Cada una tiene su propio escenario en el que se desenvuelven más cómodamente.

    El sistema tradicional SGBD no va a desaparecer porque estén de moda las NoSQL sino que progresivamente aparecerán aplicaciones que las incorporarán porque, sencillamente, serán más adecuadas. Lo normal será finalmente encontrar proyectos que utilicen ambos sistemas de forma simultánea en diferentes contextos.

    Un saludo y gracias por el artículo.

  8. Maxpowel dice:

    Hola EtnasSoft. Tengo que decirte que estoy totalmente de acuerdo contigo y que mi intención es precisamente dar a entender justo lo que explicas en tu comentario.

    No tienes más que buscar en google “sql vs nosql” para encontrar un montón de sitios donde la gente pregunta que cual de las dos es mejor.

    Lamento que en el artículo se de a entender que simplemente las estoy comparando ya que mi intención era hacer comparanciones “ridículas” para ver que son cosas diferentes. Es como si digo que mi coche no es tan bueno asando pollos como el horno de la cocina, es algo que no se puede comparar y a nadie se le ocurriría hacerlo. Pero sin embargo mucha gente compara las sql con las nosql cuando no es lo correcto.

    Un saludo y gracias a ti por enriquecer el artículo con tu comentario 😉

  9. bcyp dice:

    Muchas gracias por el artículo.
    Es muy claro e interesante.

    Por lo poco que lei por ahí, me parece que no solo las relacionales y las NoSQL tienen cada una su escenario en las que son adecuadas, sino que hay muchos tipos de NoSQL, que se aplicarían a situaciones distintas.

  10. sergio dice:

    Max…en cierto modo, las noSQL es un retroceso…mmm…de mySQL por ejemplo?? si no estoy mal, mySQL inicio sin tantas restricciones…sin triggers, funciones almacenadas, etc…etc…
    Entiendo lo q explicas al igual lo q indica EtnasSoft, pero yo asi lo veo en un momento dado, claro q es una alternativa para hacer cosas diferentes para situaciones diferentes de hoy en día, puesto q el tratamiento de la informacion ah cambiando mas ahora con las redes sociales y las wikis

  11. Maxpowel dice:

    Hola Sergio, podría considerarse un retroceso desde el punto de vista de las prestaciones, como tu has mencionado.
    Sin embargo se hace por un motivo muy concreto que es la velocidad.

    Me explico con un ejemplo, los coches. En el uso cotidiano de un coche a todos nos gusta que tenga aire acondicionado, hueco y asientos cómodos… Sin embargo, todas esas comodidades afectan directamente al rendimiento del motor (el aire consume unos caballos de potencia, más peso…) lo que implica que la velocidad punta tanto como aceleración será menor. En resumen, este coche nos será muy comodo de utilizar y cubre prácticamente cualquier situación.

    En cambio, si nos metemos en un ámbito de competición nos encontramos que a los coches les han quitado todos esos “extras” precisamente para correr más que ninguno. Este coche será más veloz que los anteriores, en cambio, sólo sirve para una cosa: correr.

    En el ámbito de las bases de datos, se renuncia a todos esos servicios a cambio de velocidad.
    Y hay que estar realmente seguro de que no vas a utilizar ninguno de esos servicios a los que renuncias (transacciones, triggers, foreign keys…)
    ya que en ese caso tocaría realizarlas fuera del dominio de la base de datos y, como digo en artículo, en ese caso mandarás el rendimiento al carajo.
    Pero bueno, no por esto hay que pensar que las SQL son lentas ni mucho menos (siguiendo el símil de los coches, serían como un deportivo de alta gama).

    Mi opinión es que ningún sistema debería cimentar su base en una noSQL, sino que se debería usar como un apoyo a una base de datos relacional (para tablas concretas o caches).

    Y para terminar, diré que las noSQL sirven para casos muy concretos y nunca deberíamos forzar la situación para usarlas ya que nos puede acarrear muchos problemas en un futuro.

  12. Alexis Advance dice:

    Max, he buscado suficiente información acerca de NoSQL —la verdad es que es difícil encontrar en español— como para dar una opinión acerca de si es realmente necesaria y si es sólo un término que está, por así decirlo, «de moda» en estos momentos.

    Coincido totalmente con tu percepción sobre esta nueva manera de almanecar datos. Me parece que puede ser eficiente (de hecho lo es; por algo se utiliza por sistemas gigantes), pero la pérdida de funcionalidades tan importantes como las que velan por la integridad de los datos —entre muchas otras— le sigue dando puntos a favor a MySQL en la gran mayoría de los casos.

    Personalmente no me convence (por ahora) la idea de utilizar sistemas de almacenamiento de datos NoSQL. Quizás en algún futuro me interese; en la actualidad me parece algo innecesario en la práctica personalmente, y creo que será así por mucho tiempo.

    ¡Saludos!

  13. TeKNo dUKe dice:

    @Maxpowel, en cuanto a lo de que consultar y los joins es bastante tendenciosa tu postura ya que estas partiendo de un modelo relacional y pretendes consultarlo como noSql cuando en una realidad noSql no tendrías ese modelo, lo más probable es que el país sea un atributo del propio usuario. Por ejemplo en mongoDb:

    > db.test.save({nombre: ‘Juan’, pais:’Italy’});
    > db.test.save({nombre: ‘Juan2′, pais:’Italy’});
    > db.test.save({nombre: ‘Juan3′, pais:’Italy’});
    > db.test.save({nombre: ‘Pedro1′, pais:’France’});
    > db.test.save({nombre: ‘Pedro2′, pais:’France’});
    > db.test.save({nombre: ‘Nano1′, pais:’Spain’});

    Y la consulta con el group queda:
    > db.test.group(
    … { key: {pais:true},
    … initial: {count: 0},
    … reduce: function(obj, prev){prev.count++;},
    … cond:{}
    … });

    (los puntos … son por el multilinea de la consola no parte de la sintaxis)

    Hago bastante acuerdo con tu postura pro SQL además agrego a tus argumentos que al momento de implementar una solución al día de hoy hay mucha más información, libros y usuarios con experiencia en el modelo relacional que en las noSql.

    Como visión personal creo que hay un gran snobismo que dice que si “twitter” o “facebook” las usan deben ser mejores y eso hace en parte caminar el mercado.

    Creo que cada una tiene su lugar y hay que usarlas a ambas pero siempre con argumentos sólidos de diseño.

  14. Maxpowel dice:

    No puedo más que darte la razón TeKNo dUKe, pero el problema que yo veo (igual para otros no es un problema) es que vas a tener mucha redundancia. Como dijo en el comentario de arriba Alexis Advance, el tema es que “va más rápido” porque sacrifica ciertas funcionalidades. Eso para unos casos irá bien y para otros irá mal, simplemente depende del caso como has dicho al final de tu comentario.

    Por lo demás, comparto totalmente tu opinión y precisamente debido ese snobismo que comentas es lo que motivó a escribir el artículo.

  15. tocoo dice:

    Creo que la visión es bastante cerrada, primero que todo para poder comparar debes conocimiento de los temas de que estás comparando, en este caso se demuestra que haber leido un par de textos no te permite conocer como funcionan las bases de datos NoSQL, primero debes tener el conocimiento para poder hacerlo.

    Por otro lado no puedes comparar bases de datos relacionales con las NoSQL, si bien las dos tienen por nombre “Bases de Datos” el como trabajan para que están orientadas son totalmente diferente, cada una tiene sus beneficios y deficiencias.

  16. Maxpowel dice:

    tocoo dime exactamente qué es lo que no es correcto y así puedo aprender. También me gustaría saber por qué opinas que soy un ignorante charlatán ya que en tu comentario no has dicho nada concreto.

    Por otro lado, precisamente trato de explicar que NO se pueden comparar y que son herramientas para cosas diferentes (con ejemplos para evidenciarlo). Ahora igual el asunto está más claro, pero lo escribí cuando en todos los sitios comparaban ambas herramientas.
    En los dos últimos párrafos (conclusiones) creo que lo dejaba claro pero veo que no lo suficiente.

  17. Carlos Alberto dice:

    El articulo me parece super interesante y creo que dependiendo nuestra necesidad debemos pensar en soluciones hibridas en donde la integridad la garantizemos con un SGBD y aquellas consultas que requieran mayor peso usemos un sistema nosql afinado de acuerdo a nuestras necesidades

    saludos

  18. godie dice:

    muy buen articulo, me aclaro varias dudas sobre nosql y veo que se puede utilizar en varios escenarios pero no serán sustituto de las sqls si no que se pueden complementar.

  19. Leonardo dice:

    Muy buen artículo! Me sacó las dudas y aclarás muy bien donde si y donde no conviene usar sql y nosql, asi como las ventajas y desventajas de cada uno.

  20. pollcaz dice:

    Excelente tu artículo, muchas gracias por intesarte en compartir tus conocimientos y experiencia no sólo en BD sino en proyectos de desarrollo de SI. Me gustaría de ser posible, que nos compartieras cómo se podría hacer para que el mismo sistema utilice ambas BD y cuales funcionalidades soportaría cada una?, Muchas Gracias!.

  21. Antoni dice:

    En referencia al autor: Sinceramente creo que estás muy equivocado. Obviamente muchas de las cosas que dices son ciertas, pero en otras te estas equivocando radicalmente.
    Si me pides mi opinión te diré que en algunos casos MySQL es muy adecuada, pero para otras las NoSQL son la solución.
    Resumiendo mucho:
    Muy poca concurrencia y un modelo relacional complejo: MySQL
    Mucha concurrencia y necesidades de Escalabilidad: NoSQL.

    Soy asesor IT en Amazon.

  22. Maxpowel dice:

    Buenas Antoni, creo que definitivamente no me he expresado bien pero ese resumen tuyo es precisamente lo que quería transmitir.

    No quería simplificar tanto y por eso he puesto ciertos casos.

    Si me dices dónde estoy equivocado te lo agradecería.

    Un saludo

  23. Víctor Lenin dice:

    Buenas Amigo, pues el NOSQL tiene un contexto y no es aplicado a Empresas comunes y silvestres, es por ello que lo utilizan las empresas que tienen o manejan grandes volúmenes de datos pues en esos casos soluciona los problemas de cuellos de botella que se originan dando mayor escalabilidad horizontal.
    saludos

  24. Eragonz dice:

    hola man quiza sea inoportuno y no venga al tema esta pregunta pero podrias enseñarme como haces para q tus comentarios muestren el navegador y el ssoo q utiliza el que los escribe? te lo agradeceria un monton si puedes escribeme al correo gracias =)!

  25. Eragonz dice:

    Otra cosita como dice un comentario anterior seria bueno que explicaras con un ejemplo como se podria complementar mysql y nosql, seria de gran utilidad gracias y cdt =)

  26. si lo usan los grandes: facebook, google etc… creo que tambien yo deberia usarlo

  27. René Rueda dice:

    La velocidad de almacenamiento y proceso de datos dependen del programador, no del gestor de bases de datos, si dominas las herramientas de programación tanto del servidor como las del cliente puedes superacelerar los procesos al grado de que los usuarios tengan la total sesación de estar utilizando una aplicación para escritorio.

  28. rootBash dice:

    Excelente aporte! gracias por compartirlo! pero mi unica
    inconformidad es el no comparar sql con nosql! y tampoco decir que uno hace esto y el otro no.

    Y claro que la respuesta esta desde el principio! es decir cada cual pertenece a un escenario diferente. pero a mi parecer no yo siempre lo he entendido como: todo se deduce entre una y tantas cosas a “escalabilidad” la escencia de las nosql es eso!
    A parte tu post nos da la escencia que se inspira mas a una deficiencias que a critica!! hay que saber cual es la diferencia entre una y otra.
    Desde un principio tu dices “nosql” no hace bien esto, le hace falta aquello, (concurrencia), y una critica seria por decir “no me gusta como interactuo con esto” o .. me gustaria que su portabilidad se dedujera a esto etc.
    Es decir debes ser mas explicito, por mi parte me considero ignorante porque todos los dias aprendo muchas cosas! pero he aprendido que si digo algo debo ser claro y consiso y la magia siempre esta en “preguntar” porque nadie nos garantiza que lo que nos dicen sea verdad! y los que nos dan las respuestas son los libros, debes entender que del otro lado estamos personas que aveces no captamos bien y estas creando mounstritos que piensan que una consulta es mejor en sql que en una nosql!!

    Tu post esta excelente pero solo me limito a que hubieras dicho mejor””esta consulta en sql se hace asi,, y esta misma consulta en nosql se hace asi!!y al final terminar con un comentario que son cosas muy diferentes!!
    tu post me recuerda a la pelea entre windows y linux!! es como si tu hablaste todo lo bueno de windows(tiene juegos,office) y linux le hechaste mucha tierra !!!!ojo son sistemas muy diferentes y para ambitos muy diferentes!! asi o mas claro ..saludos!

  29. oscar dice:

    Hola,
    Personalmente me parece un artículo bueno y por eso decido comentar.
    Andaba buscando información sobre noSQL, ya que tengo en mente algunos proyectillos y “tope” con este blog y esta entrada que desconocía.

    Gracias a este artículo ahora tengo claro que debo usar las dos, tanto relacionales como noSQL, así pues para las relaciones y todo eso usare MySQL (mejor MariaDB jeje) y para la parte en la que solo necesito insertar y mostrar datos usare noSQL.

    Una vez más gracias.

  30. Elestudiantefantasma dice:

    Muy buen tema, me gusto mucho, solo hay algo que no entiendo muy bien sobre nosql ¿a que se refieren con escalabilidad? ¿que es lo que si puede hacer nosql con respecto a las bases de datos slq en el tema de escalailidad?
    yo soy de la idea de dar el paso lento pero seguro y me inclino mas a las bases de datos relacionales.

    Tambien me surgio otra duda ¿que diferencia hay entre las nosql y mysql en MyISAM?
    por que hasta donde yo se, cuando haces una base de datos en MyISAM, no puedes trabajar con llaves primarias ni foraneas, trabajas con indices y la ventaja que tiene es que puedes hacer inserciones y consultas sencillas mas rapidas que en innodb, pero como desventaja, las bases de datos pierden integridad.

    Gracias y espero tu respuesta amigo :)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *