Quelle est la différence entre les bases de données basées sur un graphe (http://neo4j.org/) et les bases de données orientées objet (http://www.db4o.com/)?Quelle est la différence entre les bases de données à base de graphes et les bases de données orientées objet?
Je réponds différemment: les bases de données d'objets et de graphiques fonctionnent sur deux niveaux d'abstraction différents.
Les principaux éléments de données d'une base de données objet sont des objets, comme nous les connaissons à partir d'un langage de programmation orienté objet.
Les principaux éléments de données d'une base de données graphique sont des noeuds et des arêtes.
Une base de données d'objets n'a pas la notion d'un bord (bidirectionnel) entre deux choses avec l'intégrité référentielle automatique etc. Une base de données de graphe n'a pas la notion d'un pointeur qui peut être NULL. (Bien sûr, on peut imaginer des hybrides.)
En termes de schéma, le schéma d'une base de données d'objets est quel que soit l'ensemble des classes dans l'application. Le schéma d'une base de données de graphe (implicite, par convention de ce que les étiquettes de chaîne signifient, ou explicite, par déclaration comme modèles comme nous le faisons dans InfoGrid par exemple) est indépendant de l'application. Cela rend beaucoup plus simple, par exemple, d'écrire plusieurs applications sur les mêmes données en utilisant une base de données de graphe au lieu d'une base de données d'objets, car le schéma est indépendant de l'application. D'autre part, en utilisant une base de données graphique, vous ne pouvez pas simplement prendre un objet arbitraire et le conserver.
Différents outils pour différents travaux, je pense.
D'un oeuil rapide de leurs deux sites:
La principale différence est la façon dont les API sont structurées, plutôt que le type de base de données de forme libre vous pouvez construire avec eux. Db4o utilise un mappage d'objet: vous créez une classe Java/C# et il utilise la réflexion pour le conserver dans la base de données.
neo4j possède une API de manipulation explicite. Neo4j semblait, à mon humble avis, beaucoup plus agréable d'interagir avec.
Vous pouvez également envisager un magasin de valeurs-clés - vous pouvez créer exactement la même base de données libre avec l'une d'entre elles.
Comme le décrira sous un autre angle, un graphdb conservera vos données séparées de vos classes d'application et de vos objets. Un graphdb a également plus de fonctionnalités intégrées pour traiter les graphes, évidemment - comme le plus court chemin ou des traversées profondes. Une autre différence importante est que dans un graphdb comme neo4j, vous pouvez traverser le graphe en fonction des types et directions de relation (bord) sans charger les nœuds complets (y compris les propriétés/attributs de nœud). Il y a aussi le choix d'utiliser neo4j comme backend d'un objet db, tout en étant capable d'utiliser tous les trucs graphiques, voir: jo4neo Ce projet a une approche différente qui pourrait aussi compter comme un objet db au-dessus de neo4j: neo4j.rb. Une nouvelle option consiste à utiliser Spring Data Graph, ce qui permet de prendre en charge graphdb via des annotations. La même question a été posée dans les commentaires au this blogpost.
Avec les bases de données de graphes, vous avez un léger semblant de chance d'être basé sur la théorie mathématique des graphes. Avec les bases de données orientées objet, vous avez la certitude qu'il ne repose sur rien du tout (et certainement pas de théorie mathématique du tout).
Oui, l'API semble être la différence majeure, mais elle n'est pas vraiment superficielle. Conceptuellement, un ensemble d'objets formera un graphique et vous pourriez penser à une API qui traite ce graphique de manière uniforme. Inversement, vous pouvez théoriquement extraire une structure de graphe générique pour les motifs et les mapper aux objets exposés via une API. Mais la conception de l'API d'un produit réel aura généralement des conséquences sur la façon dont les données sont réellement stockées, comment il peut être interrogé, il serait donc loin d'être trivial de créer un wrapper et de le faire ressembler à autre chose. En outre, une base de données orientée objet doit offrir des garanties d'intégrité et une structure de typage qu'une base de données graphique ne fera normalement pas. En fait, la base de données OO sérieuse est loin de la "forme libre" :)
Jetez un coup d'oeil à [HyperGraphDB] [1] - c'est à la fois une base de données complète orientée objet (comme db4o) et une base de données de graphes très avancée en termes de capacités de représentation et d'interrogation. Il est capable de stocker des hypergraphes généralisés (où les arêtes peuvent pointer vers plusieurs nœuds et également vers d'autres arêtes). Il possède un système de type entièrement extensible incorporé comme un graphique, etc.
Contrairement à d'autres bases de données de graphes, dans HyperGraphDB chaque objet devient un noeud ou une arête dans le graphe, avec une intrusion API non-minime et vous avez le choix de représenter vos objets sous forme de graphe ou de les traiter de manière orthogonale à la structure du graphe (comme "charge utile" valeurs de vos noeuds ou arêtes). Vous pouvez faire des traversées sophistiquées, indexation personnalisée et interrogation.
Une explication de la raison pour laquelle HyperGraphDB est en fait un ODMS, voir l'article de blog HyperGraphDB est-il une base de données OO? sur le site Web de Kobrix.
La différence au bas niveau n'est pas si énorme. Les deux gèrent les relations comme des liens directs sans jointures coûteuses. En outre, les deux ont un moyen de traverser les relations avec le langage Query, mais la base de données de graphes a des opérateurs pour aller récursivement au niveau Nième. Mais la plus grande différence est dans le domaine: dans une base de données Graph tout est basé sur les 2 types: vertex et bords, même si généralement vous pouvez définir vos propres types comme une sorte de sous-types de Vertex ou Edge.
Dans l'ODBMS, vous n'avez pas de concepts Vertex et Edge, sauf si vous écrivez les vôtres.