This means that the direct reference lets you traverse the graph without the overhead that relational system have.

So traversals almost come for free, while, given a tree ( which, by the way, is a directed graph with no cycles ), in a relational system you should do expensive queries in order to extract it.

Doing it with the parent_id means that you are basically trying to rape your DB, doing it with some algorithm like the nested set means that you are loosing some great advantages of RDBMS.

Some relations in OrientDB

OrientDB has some cool data types to handle relations.

First of all, it has embedded stuff, like MongoDB.

Orient divides relation type in embedded or link relations.

Embedded relation are the ones where the element connected to an object lives only in the context of that object ( thus, for instance, they have no record id ) while the linked ones are real objects connected to an object.

So for example, a Post can have many embedded tags:

123

Post:title:My posttags:agile, php

or links to tag entities:

123

Post:title:My posttags:[2:1,2:2]// given 2 as the cluster where you store tags

Given these 2 different relation types, you can choose among three main data structures to store them:

[embedded|link] list, which is a series of ordered relations

[embedded|link] set, which is a series of unordered relations

[embedded|link] map, which is a series of key/value pairs

Structure of a graph

The standardized way to structure a graph is pretty straightforward, because you have 3 entities: nodes ( your objects ), edges ( the connections between them ) and properties ( that are assigned to both of the previous ).

For example, the triples can be defined like in the following snippet:

Structure of OrientDB

Mmmm, so you are probably asking yourself: how the hell can I use this triples in a web-oriented product?

My short answer is: you probably can’t.

Graph databases help you, for example, when you need to write GPS car navigation systems or stuff like that. But the web hates triples.

So, you are probably thinking that a product like OrientDB won’t ever fit well in your projects, and you are totally wrong.

The cool thing about OrientDB is that it is a graph database built upon a document one ( or probably the inverse, I don’t exactly know ), so it’s able to perform like a common graph but lets you structure your data like a document-oriented database.

Products like Neo4j aren’t able to avoid triples for your data structures, and that’s why I think that OrientDB will be the precursor of the web-oriented graph databases.