What is the difference between graph-based databases and object-oriented databases?

Question

What is the difference between graph-based databases ( http://neo4j.org/ ) and object-oriented databases ( http://www.db4o.com/ )?

Answer 1

I would answer it differently: databases of objects and graphs work at two different levels of abstraction.

The main elements of the database data objects are objects, as we know them in an object-oriented programming language.

The main elements of the graph database data are nodes and edges.

The object database does not have the concept of a (bi-directional) edge between two things with automatic referential integrity, etc. There is no concept of a pointer in a graph database, which can be NULL. (Of course, you can imagine hybrids.)

In terms of schema, a schema of an object database is what a set of classes are in the application. The graph database schema (regardless of whether it is implied by the concept denoted by String characters, or by explicit declaration as models, as we do in InfoGrid for example) is application-independent. This makes it much easier, for example, to write several applications against the same data, using the graph database instead of the object database, since the scheme is application independent. On the other hand, using the graph database, you cannot just take an arbitrary object and save it.

Different tools for different tasks that I think of.

Answer 2

Yes, the API seems to be a big difference, but is not really superficial. Conceptually, a set of objects will constitute a graph, and you could think of an API that processes this graph in a unified form. And vice versa, theoretically you could create a general graph structure for templates and map them to objects opened through some API. But the API design of the actual product, as a rule, has consequences for how the data is actually stored, how it can be requested, so it would be far from trivial, for example, to create a shell and make it look like something else. In addition, an object-oriented database should offer some guarantees of integrity and input structure, which usually do not use the graph database. In fact, a serious OO database is far from "free form" :)

Take a look at [HyperGraphDB] [1] - this is both a complete object-oriented database (for example, db4o), and a very advanced graph database both in terms of representative and queries. It is able to store generalized hypergraphs (where edges can point to more than one node, as well as to other edges), it has a fully extensible system, built-in in the form of a graph, etc.

Unlike other graphical databases, in HyperGraphDB each object becomes a node or edge on the graph, with an uninteresting API intrusion, and you have the choice to present your objects in the form of a graph or to process them in such a way that is orthogonal to the graph structure (as the values ​​of the “payload” "of your nodes or edges). You can perform complex crawls, customize indexing and queries.

For an explanation of why HyperGraphDB is actually an ODMS, see the blog post. Is HyperGraphDB an OO database? on the Kobrix website.

Answer 3

As Will descibes from another angle, graphdb will store your data separately from your application classes and objects. Graphdb also has more built-in functionality for processing graphs, obviously as a shortcut or deep workarounds.

Another important difference is that in a graph like neo4j, you can cross the graph based on types (directions) and relationship directions without loading all nodes (including node properties / attributes). There is also the choice of using neo4j as the backend of a db object, which can still use all GUI materials: jo4neo This project has a different approach, which can also be considered a db object on top of neo4j: neo4j.rb . A new option is to use the Spring Data Graph , which provides graphical interface support through annotations.

The same question was asked in the comments on this blogpost .

Answer 4

From a quick look at both of their websites:

The main difference is how the APIs are structured, and not as a free-form database that you can build with them.

db4o uses object mapping - you create a Java / C # class, and it uses reflection to store it in the database.

neo4j has an explicit manipulation API.

Neo4j seemed, in my humble opinion, much nicer to interact with.

You can also consider storing key values ​​- you can make the exact same free-form database with one of them.

Answer 5

The difference at a low level is not so great. Both manage relationships as direct links without costly associations. In addition, both have a way of intersecting relations with the query language, but there are operators in the graph database that recursively go to the Nth level.

But the biggest difference in the domain: in Graph databases, everything is based on two types: vertices and edges, even if you can usually define your own types as a kind of subtype of Vertex or Edge.

In ODBMS, you do not have the concepts of Vertex and Edge unless you write your own.

Answer 6

Using graphical databases, you have little chance of being based on mathematical graph theory. With object-oriented databases, you have confidence that it is based on nothing (and, of course, not on mathematical theory in general).