¿Cuál es la diferencia entre las bases de datos basadas en gráficos (http://neo4j.org/) y las bases de datos orientadas a objetos (http://www.db4o.com/)?¿Cuál es la diferencia entre las bases de datos basadas en gráficos y las bases de datos orientadas a objetos?
Respondería esto de manera diferente: las bases de datos de objetos y gráficos funcionan en dos niveles diferentes de abstracción.
Los elementos de datos principales de una base de datos de objetos son objetos, la forma en que los conocemos desde un lenguaje de programación orientado a objetos.
Los elementos de datos principales de una base de datos de gráfico son nodos y bordes.
Una base de datos de objetos no tiene la noción de un borde (bidireccional) entre dos cosas con integridad referencial automática, etc. Una base de datos de gráficos no tiene la noción de un puntero que puede ser NULO. (Por supuesto, uno puede imaginar híbridos.)
En términos de esquema, el esquema de una base de datos de objetos es el que sea el conjunto de clases en la aplicación. El esquema de una base de datos de gráficos (ya sea implícita, por convención de lo que significan las cadenas de etiquetas, o explícito, por declaración como modelos como lo hacemos en InfoGrid por ejemplo) es independiente de la aplicación. Esto hace que sea mucho más simple, por ejemplo, escribir múltiples aplicaciones contra los mismos datos usando una base de datos de gráficos en lugar de una base de datos de objetos, porque el esquema es independiente de la aplicación. Por otro lado, al utilizar una base de datos de gráficos, no puede simplemente tomar un objeto arbitrario y persistir.
Distintas herramientas para diferentes trabajos, creo.
De un vistazo rápido de ambos sus sitios web:
La principal diferencia es la forma en que se estructuran las API, en lugar de la clase de base de datos de forma libre se pueden construir con ellos.
db4o usa una asignación de objetos: crea una clase Java/C# y utiliza la reflexión para conservarla en la base de datos.
neo4j tiene una API explícita de manipulación.
Neo4j parecía, en mi humilde opinión, mucho más agradable para interactuar.
También podría considerar una tienda de valores-clave: podría hacer exactamente la misma base de datos de forma libre con una de esas.
Como Will lo describe desde otro ángulo, un graphdb mantendrá sus datos separados de las clases y objetos de su aplicación. Un graphdb también tiene más funcionalidad incorporada para tratar con gráficos, obviamente, como el camino más corto o los recorridos profundos.
Otra diferencia importante es que en un graphdb como neo4j puede recorrer el gráfico en función de los tipos de relación (borde) y direcciones sin cargar los nodos completos (incluidas las propiedades/atributos del nodo). También existe la opción de usar neo4j como backend de un objeto db, aún siendo capaz de usar todo el material gráfico, ver: jo4neo Este proyecto tiene un enfoque diferente que también podría contar como un objeto db en la parte superior de neo4j: neo4j.rb. Una nueva opción es usar Spring Data Graph, que brinda soporte de graphdb a través de anotaciones.
Se hizo la misma pregunta en los comentarios al this blogpost.
Con las bases de datos de gráficos, tiene una pequeña posibilidad de que se basa en la teoría matemática de gráficos. Con las bases de datos orientadas a objetos, tiene la certeza de que no se basa en nada (y ciertamente no tiene ninguna teoría matemática).
Sí, la API parece ser la principal diferencia, pero en realidad no es una superficial. Conceptualmente, un conjunto de objetos formará un gráfico y se podría pensar en una API que trate este gráfico de manera uniforme. Por el contrario, en teoría podría extraer una estructura gráfica genérica para patrones y asignarlos a objetos expuestos a través de alguna API. Pero el diseño de la API de un producto real generalmente tendrá consecuencias sobre cómo se almacenan realmente los datos, cómo se puede consultar, por lo que no sería trivial, por ejemplo, crear un contenedor y hacer que parezca algo más. Además, una base de datos orientada a objetos debe ofrecer algunas garantías de integridad y una estructura de tipeo que una base de datos de gráficos no hará normalmente. De hecho, la base de datos OO seria está lejos de ser "forma libre" :)
Eche un vistazo a [HyperGraphDB] [1] - es una base de datos orientada a objetos completa (como db4o) y una base de datos de gráficos muy avanzada en términos de capacidades de representación y consulta. Es capaz de almacenar hipergramas generalizados (donde los bordes pueden apuntar a más de un nodo y también a otros bordes), tiene un sistema de tipo totalmente extensible incrustado como un gráfico, etc.
A diferencia de otras bases de datos de gráficos, en HyperGraphDB cada objeto se convierte en un nodo o un borde en el gráfico, con una intrusión de la API de no mínima o mínima y usted tiene la opción de representar sus objetos como un gráfico o tratarlos de una manera que es ortogonal a la estructura del gráfico (como "carga útil" valores de sus nodos o bordes). Puede realizar recorridos sofisticados, indexación personalizada y consultas.
Una explicación de por qué HyperGraphDB es, de hecho, un ODMS, ver la publicación del blog ¿HyperGraphDB es una base de datos OO? en el sitio web de Kobrix.
La diferencia a bajo nivel no es tan grande. Ambos manejan las relaciones como enlaces directos sin costosas uniones. Además, ambos tienen una forma de atravesar las relaciones con el lenguaje de consulta, pero la base de datos de gráficos tiene operadores para ir recursivamente en el nivel N-ésimo.
Pero la mayor diferencia está en el dominio: en una base de datos Graph todo se basa en los 2 tipos: vértices y bordes, aunque normalmente puede definir sus propios tipos como un tipo de subtipos de Vertex o Edge.
En el ODBMS no tiene conceptos de Vértice y Borde, a menos que escriba uno propio.