2010/2/25 Federico Brubacher <[email protected]> > > Creo que no todas los data-store no relacionales se manejen con map-reduce, > creo que hay varios q usan :hashing así que el lookup seria en tiempo > constante (habría q ver para una gran cantidad de objetos-hash seria mejor un > árbol ?) . De cualquier manera una ventaja de las bases relacionales es que > son buenas en transacciones. > > 2010/2/25 Michel Martens <[email protected]> >> >> 2010/2/25 Fernando Parra <[email protected]>: >> > Se que esto no está relacionado directamente a Ruby, pero creo que es de >> > interés para la mayoría. >> > Actualmente estoy leyendo mucho sobre la movida NoSQL y opino que es un >> > paradigma muy necesario considerando los volúmenes de datos y las >> > necesidades que los sistemas de información presentan. >> > Ahora, me parece muy lindo el concepto, pero hay un caso que no me queda >> > claro de todas las explicaciones que he escuchado, y me hace sospechar que >> > por ahí las bases de datos relacionales siguen estando vigentes (dado que >> > hay muchos fanáticos que proponen desecharlas completamente). >> > El tema es el siguiente: supongamos un sistema comercial en el cual tendría >> > miles de datos en tablas maestras con información como: roles, países y >> > ciudades, códigos de productos, etc. Es muy probable (y sobre todo al >> > principio) que no se hayan realizado por ej, ventas de cierto producto, o >> > no >> > se hayan asignado roles a ciertos usuarios, lo que se traduce en que un >> > registro de una tabla aún no se ha relacionado con otra al menos una vez. >> > En NoSQL se propicia la utilización de algoritmos Map Reduce del cual se >> > podría extraer de un set los datos que corresponden a valores únicos (por >> > ejemplo, los países que integran los usuarios de nuestro sitio), pero al >> > hacer esto no estaríamos tomando en cuenta todo el set posible. Nada me >> > suena mejor que un OUTER LEFT JOIN si estuviera utilizando SQL. >> > Si para solucionar esto agregáramos una colección conteniendo los datos de >> > lookup, estaríamos simulando una situación típica de una base relacional y >> > me parece que nadie lo recomendaría. >> > Me imagino esta situación en un sistema transaccional todo el tiempo. >> > Cual es la mejor aproximación??? >> > He leído por ahí que muchos mezclan bases relacionales con no relacionales, >> > lo cual me parece correcto, por que se estaría utilizando la mejor >> > herramienta para cada dominio. Pero, aún así, he leído de algunos >> > evangelistas NoSQL que no sería una buena práctica. Entonces? >> >> Está bueno el planteo. Te parece pasarlo a código y vemos cuál sería >> la equivalencia? Si podés armate un ejemplo de cómo serían las tablas, >> el resultado que querés obtener y cómo lo obtendrías con SQL. >> >> Saludos, >> >> -- >> Michel
No hay equivalencia de RDBMS a Hash Key, Document Oriented, Big Table, punto. Si la base de datos no está populada, no hay forma de hacer consultas de lookup. Es decir, se pueden hacer lookups siempre y cuando esten cargados en la memoria de la aplicación, lo cual es sumamente embarroso. Imagínense una lista de SKUs de 50.000 unidades cargadas en memoria. La solución son las bases de datos orientadas a Graphs como Neo4J donde podes asociar objetos entre sí como sucede en la vida real (ventaja eterna de un RDBMS salvando los JOINS que son extremadamente costosos de ejecutar). Es una forma increíble de generar estructuras débiles y al mismo tiempo evitar duplicación de datos como en los demás casos. Me parece que la zona gris entre las dos tecnologías es resuelta con esta última. El único downside es la complejidad, pero suena razonable. _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
