que no se siente lo suficientemente experimentado con ambos mundos para responder adecuadamente y plenamente su pregunta, sin embargo yo estoy usando una base de datos de documentos durante algún tiempo y he aquí algunos consejos personales.
Las bases de datos de documentos se basan en un concepto de clave, valor y vistas estáticas, y son geniales para encontrar un conjunto de documentos que tengan un valor particular.
Ellos no conceptualizan las relaciones entre los documentos.
Si su software tiene que proporcionar "consultas" avanzadas donde los criterios de selección actúan en varios "tipos de documento" o si simplemente necesita realizar una selección utilizando varios elementos, el concepto [clave, valor] no es apropiado.
También hay una serie de otros casos en los que las bases de datos de documentos son inapropiados: la presentación de grandes conjuntos de datos en tablas "paginado", se puede ordenar en varias columnas es uno de los casos en los que las actuaciones están bajo uso y espacio en disco es enorme.
Por lo tanto, en muchos casos tendrá que realizar el procesamiento "del lado del servidor" para recoger las piezas, y con rieles, o cualquier otro marco basado en ruby, puede tener problemas de rendimiento.
La base de datos de gráficos se basa en el concepto de tripplestore, lo que significa que también conceptualizan las relaciones entre las entidades.
El gráfico puede atravesarse utilizando las relaciones (y los roles de entidad), y puede ser más conveniente cuando se realizan búsquedas a través de datos estructurados por relación.
Como no tengo experiencia con la base de datos de gráficos, no estoy al tanto de si la base de datos de gráficos puede ser fácilmente consultada/atravesada con varios criterios, sin embargo, si un lector aconsejado tiene tal información, realmente apreciaría ejemplos de tales consultas/recorridos.
que estoy leyendo actualmente sobre InfoGrid y tratando de averiguar si tales bases de datos podrían muy bien por el fin de realizar peticiones complejas en un muy gran conjunto de datos, las relaciones incluidos ....
De lo que puedo leer , el InfoGrah debe considerarse como un "federador de datos" capaz de buscar/extraer los datos de varias fuentes (Tiendas) que también pueden ser una base de datos NoSQL como Mongo.
Wich significa que usted podría utilizar un almacén de mongo para las actualizaciones y infografía para la búsqueda de datos, y tal vez ahorrar una gran cantidad de CPU y el disco cuando se trata de búsquedas complejas dentro de una base de datos NoSQL.
Por supuesto, puede parecer un poco "exagerado" si su aplicación simplemente almacena un gran conjunto de enormes archivos binarios en una base de datos y todo lo que necesita es realizar consultas simples y recuperar el resultado. En ese caso, una base de datos nosql como mongo o couch probablemente sería útil.
esperanza alguna de esta ayuda;)
Muy buen artículo, gracias! – devlearn