Portada
mis comunidades
otras secciones
#3:
Joder. Qué titular más sensacionalista.
¿Qué más dará que sea Mongo DB que SQL Server?
Lo que importa son los hechos.
¿Qué más dará que sea Mongo DB que SQL Server?
Lo que importa son los hechos.
Comentarios
Joder. Qué titular más sensacionalista.
¿Qué más dará que sea Mongo DB que SQL Server?
Lo que importa son los hechos.
#3 Aprovecharán un descuido de sus responsables para vender la idea de que es insegura.
Tal vez el autor sea un integrista relacional.
#3 Si no usas Mongo eres idem.. debe pensar el becario.
#3 #5 hago de abogado del becario: estoy pensando que el hecho de que sean colecciones de documentos y por tanto los datos puedan ser vistos más fácilmente estructurados sin requerir consultas complejas en un modelo relacional, habrá podido facilitar la detección de la estafa y por eso hablar de MongoDB ?
#8 #3 Básicamente lo que ocurre es que tú y yo sabemos que el que sea MongoDB o MariaDB o PostgreSQL es irrelevante, pero el que ha esrito la noticia no lo sabe, y como ha leído por ahí que la base de datos es MongoDB y eso suena a algo pues lo pone en el titular.
Es lo que siempre pasa con los periodistas cuando escriben de todo sin saber de nada.
No podían usar otra BD.
#2 MongolicDB pedó fuerte hace años, mogollón de "desarrolladores" se fliparon y pensaron que ése era el camino a seguir. Y nada, a implementar aplicaciones tradicionales con sus bases realmente relacionales... en MongolicDB.
Ya se les ha pasado, creo.
#6 el problema de Mongo db ha sido para mi gusto que la gente aún no sabe trabajar con colecciones y bdd no-sql ....
Y se dan unos leñazos diseñando los modelos que alucinas. De todos modos para algunas aplicaciones es más que mejor que muchas db sql relacionales normales y corrientes
De hecho el stack MEAN completo, es un pack de desarrollo brutal
MongoDB/Mongoose
Express.js
Angular.js
Node.js
#7 Yo es que soy muy carca, y además he pasado de ponerme las pilas con "nuevos" frameworks y librerías, pero le he cogido una manía tremenda a muchas cosas precisamente porque se intentan buscar soluciones a problemas que no existen, y se complican las cosas con la excusa de simplificarlas o mejorar el mantenimiento. Luego resulta que añadir una columna en una tabla de mierda con un botón les lleva día y medio y que se lo tenía que haber dicho antes
No dudo que para aplicaciones más orientadas a documentos o colecciones de texto no tenga su uso, pero las típicas aplicaciones CRUD o de procesamiento de datos... pa qué meterte en chorradas.
#9 no creas. El “pequeño” detalle de que utilicen Bson/Json como formato por defecto de almacén/intercambio tiene sus ventajas claras: no debes hacer marshalling para aplicaciones basadas en micro servicios (las que se ha demostrado con mayor escalabilidad) lo que las hace menos pesadas y con mejores rendimientos para algunas operaciones ...
#11 Y repetir entidades una y otra vez? no s'e, no lo veo. No te digo que para ciertos tipos de aplicaciones m'as orientadas a documentos, texto, etc... est'e muy bien. Pero es que todos los projectos en los que he trabajado realmente requer'ian modelos relacionales, con muchas entidades y muchas relaciones.
Me suena de haber le'ido en su d'ia que la mayor parte de la rapidez de MongoDB ven'ia a consecuencia de guardar en cach'e (en la RAM) mogoll'on de 'indices y datos. Claro, as'i yo tambi'en hago acceso de datos ra'pido, no te jode. De hecho con MariaDB (y MySQL) tambi'en puedes decir que cachee m'as y m'as :P. Y ya si te pones no hace falta ni que uses un SGDB. Yo me hice mi framework MVC hace ya unos a;os y ten'ia un sistema de cach'e de respuestas ya generadas, indexado por controlador + m'etodo + par'ametros. Al principio usaba APC para guardar el 'indice en la RAM. Cuando me mov'i de servidor y se negaron a instalar esa extensi'on sin sajarme, opt'e por hacerme otro "driver" para dicho m'odulo que serializara el 'indice y lo pusiera en un archivo.
Si tus aplicaciones son tan sencillas, te puedes hacer tu gestor de base de datos guardando todo en JSON o serializado como te salga de las pelotas y tener un sistema sencillo de cache. Y seguro que hasta va m'as r'apido que MongolicDB
Peque;a nota: recuerdo haber le'ido tambi'en quejas sobre MongolicDB no asegur'andote que los datos que necesitas est'en accesibles, porque la p'agina puede estar en memoria o no, provocando errores importantes. Luego ya lo solucionaron creo.
#12 No necesariamente pequeñas aplicaciones. ..... ni tan sencillas .....
https://www.mongodb.com/who-uses-mongodb
No cuentas con los costes de desarrollo y de integración continua, que se reducen de modo salvaje con bases de datos nosql....
Ah.,, y un documento json puede ser muy complejo siendo solo una colección..... en cambio en un modelo relacional son bastantes tablas combinadas ... creo que te dejas mucho por tener en cuenta .....
https://blog.philipphauer.de/databases-challenge-continuous-delivery/
#13 Sinceramente el impacto en los costes de desarrollo relacionados con tener un json o columnas en tablas es despreciable en una aplicación en la que se hace necesario modificar y cruzar datos en distintas partes de una aplicación. No digo que MondoDB o NoSQL se usen sólo en aplicaciones sencillas (de hecho, hay SGDB interesantes que modelan redes, lo cual seguro que tiene aplicaciones más complejas e interesantes que las altas bajas y modificaciones).
Eso de que usar NoSQL reduce los costos salvajemente lo tendrás que fundar en algo, porque así a botepronto me parece una afirmación muy radical y muy osada (en realidad me parece simplemente irreal).
Un JSON no es sólo una colección, del mismo modo que un modelo relacional no sólo son tablas. Pero y qué. NoSQL está orientado a lo que está orientado. Usarlo para aplicaciones con modelos relaciones es un sinsentido, y el tener que añadir columnas aquí o allá o cambiar tipos de datos NO no tiene el impacto de costes que dices ni de coña, y si lo tuviera es porque el código de la aplicación tiene que ser modificada en distintos puntos, modelos y vistas y procesos lógicos, y entonces suena a que usar NoSQL para el modelo de datos no sólo no te quita de hacer esas cosas, sino que es una idea malísima de entrada.
#13 Pero vamos, que como digo te dejes de historias y te escribas tu gestor de bases de datos con no más de 10 métodos para escribir, leer, buscar, cachear y cuatro chorradas más y ya tienes el sistema definitivo en el que tu cliente no tiene que esperar a que te sientes delante del ordenador, con un chasquido de dedos la aplicación ya está hecha a coste negativo.
#15 díselo a todos los que lo usan
Está claro que no pensamos igual. Si me preguntas no me comas la oreja por favor.
https://devops.com/why-nosql-new-database-darling-devops/
Ahí tienes los motivos
PD: trabajo con bases de datos relacionaesl de facturación hace más de 12 años. (Con varias de hecho) no he nacido ayer. Si lo defiendo es por algo
#16 Evidentemente no pensamos igual. Pero vamos, que no te como la oreja, te digo simplemente que no estoy de acuerdo con lo que me cuentas y por qué.
Ya miraré el enlace, gracias. Estoy desactualizado en temas técnicos (y todo en general), y siempre viene bien leer un poco, aunque sea a flipados
#17 jajajjaja
Perdón que me ha salido muy brusco. No me he dado ni cuenta
A lo que voy es que realmente hay muchísimo “metacódigo” en una aplicación que llega desde entornos web a una BD y que con las nosql se reduce muchisimo ese problema.
Al final es como utilizar un hibernate, pero sin tener que tunear tanto ni tener que describir las clases java, los marshals y la puta en verso que hay que definir.
En un modelo de documentos, simplemente incluyes un documento más anidado y ya está en el modelo y llegando hasta el front sin hacer nada. En una bd relacional necesitarías índices, tablas, relaciones, modificar los SQL, los marshaller, los objetos DAO si usas .... es incomparable!!
PD: si quieres hacer algo tuneado y dedicado al cálculo, relacional y punto pelota .... eso es casi una máxima para mí ....
Pd: perdón de nuevo... soy un bruto
#18 Nah, no pasa nada. Yo soy otro bruto tambi'en jeje. He estado leyendo sobre marshaling y me cuesta entender la diferencia con serializaci'on (por lo visto aunque en Java no son la misma cosa, en Python s'i).
La movida est'a en estos dos puntos:
1) puede tu aplicaci'on usar directamente ese documento, tal cual, y s'olo ese documento?
2) ese documento que tiene otros anidados... no supone una redundancia brutal, al menos potencialmente?
En cualquier caso veo que sabes de lo que hablas, aunque sigo manteniendo mi opini'on respecto a costes y tiempos. Y m'as para aplicaiones t'ipicas . Leer'e lo que enlazastes, al menos para culturizarme!
#19
a) marshalling y serializar son lo mismo sip
1- Sí, puedes consultar únicamente los documentos anidados de una colección de usuarios. Es decir: podrías obtener una colección de direcciones si cada usuario tuviera una dirección (que es un objeto complejo con varios valores tb) dentro de sí mismo sin tener que sacar “todos los usuarios (sus valores completos)”
2- ahí está el tema. En muchos casos supone redundancia si no realizas correctamente el diseño. El tema es que si tú asumes que cuando necesitas un usuario casi siempre querrás la dirección, lo creas como un documento anidado, por ejemplo, en vez de referenciar a otra colección anidada. Digamos que tiene mucho que ver el modelo con los CRUD que vas a realizar (al menos, yo, enfocándolo así es cuando he comprendido mejor el diseño que necesitaba hacer).
Por otra parte en cuanto a temas de rendimiento entiendo que bson->json será una conversión que se hará a toda leche, mucho más que haciendo métodos y métodos específicos para cada clase (con el consiguiente coste de mantenimiento de código)
Para mi gusto, el punto del mantenimiento es incomparable a una aplicació java con jdbc y sql puro o con hibernate. No sabes la maravilla que es incluir las direcciones en el modelo y sin hacer nada que lleguen a la web , y angular te las pinte directamente xq es json ....
No me entero . Los que tengan cuentas iOs en Clash of Clans han sido hackeados?