Esta es una pregunta algo abstracta y general. Me interesan las propiedades inherentes (así como las específicas de la implementación) de los diferentes enfoques para la persistencia de datos no estructurados con muchas referencias internas (similar a un gráfico) y muchas propiedades (similar a JSON).

Como un gráfico es un superconjunto de un árbol, puede ver los DB de gráficos (por ejemplo, Neo4j) como un superconjunto de DB de documentos (por ejemplo, MongoDB). Es decir, una base de datos de gráficos proporciona toda la funcionalidad de una base de datos de documentos y, además, también permite bucles o tiene un tipo de puntero nativo, por lo que no es necesario desreferenciar las claves / identificaciones externas manualmente. Entonces, ¿hay algún punto de inflexión al llegar al agregar más referencias a sus objetos / recursos en los que está mejor con una base de datos gráfica pero antes estaba mejor con un almacén de documentos? ¿Hay ventajas en documentar bases de datos (espacio de almacenamiento, rendimiento?) O debería ir siempre con una base de datos gráfica en caso de que necesite más referencias en el futuro?

De manera similar, ¿cómo se comparan los DB de gráficos y los triplestores (por ejemplo, las tiendas RDF)? Los DB de gráfico (donde los nodos y los bordes tienen propiedades) parecen ser un superconjunto de los triplestores simples. Entonces, ¿para qué problemas (si los hay) realizar triplestores realmente mejor, digamos Neo4j? (Una de las ventajas de las tiendas RDF es que existe un lenguaje de consulta estandarizado, SPARQL, aunque parece que hay muchas personas a las que no les gusta SPARQL y, por lo tanto, lo llamarían una desventaja).

Supongo que mi pregunta es: el modelo gráfico (con propiedades) parece poder expresar claramente todo tipo de datos, ¿cuál es el problema cuando entras en la realidad? Supongo que la captura de los DB de gráficos es el rendimiento, por lo que me encantaría ver algunos números o reglas generales sobre qué tipo de desaceleración se espera al cargar, consultar y modificar datos y memoria, y requisitos de almacenamiento persistentes (en comparación con el documento y tiendas triples). Además, ¿qué pasa con la escalabilidad horizontal? Tengo la impresión de que allí el campo de juego es bastante nivelado.

¿Cree que es posible que los gráficos con su expresibilidad se conviertan en el nuevo modelo de almacenamiento predeterminado para proyectos que no tienen datos muy grandes, o estamos condenados por una década dePersistencia políglota ¿Con RDBMS, las tiendas JSON y Graph DBs que viven juntas, que deben integrarse con más código de cola?