OrientDB : Edges vs LinkList vs Linkmap

Question

What are the pros and cons for using either a linklist, a linkmap or an edge to store relationships between my vertices ?

Dobbs

I personally find the answer here quite helpful as it explains the LINKS* type elements relate to documents not the graph. stackoverflow.com/questions/28673096 – Granddad

Answer 1

An edge defines a relationship between two vertices. For example, you define two vertices, Person and Car. You then define an Edge Drives. This edge ties the two vertices together. "Jane" Drives "Ford".

A linklist is a list of classes associated with another class. A Car class might have a linklist of parts from the Part class. A car consists of multiple parts.

A linkmap is a map of key, class values associate with another class. A car class might have a linkmap of PartType, Part. A car consists of multiple parts, which can be grouped by engine, body, chassis, etc.

Halfslip

+1 for the nice exemple. I still can't tell when it's better to use a linklist instead of an edge. If I take your exemple, the Car has multiple Parts(there is also a relationship between the two vertices). Why shouldn't I create multiple edges instead of a linklist ? – Dobbs

@AlexB: if you want to know what parts make up a car, a linklist is appropriate. If you want to know what cars a part is used in, as well as what parts make up a car, then you would use edges. Edges require more storage space than a linklist. – Halfslip

Edges allow for bi-directional navigation and are the right choice if you need to walk thru a graph. – Reticle

Answer 2

Quite a bit late for arrival, but I was looking for this answer recently and figured it out a bit clearly.

Links in OrientDB provides the equivalent of foreign-key relations in the relational database world. If you consider tables as classes then the link connects between two classes

In their 3.0 manual under http://orientdb.com/docs/3.0.x/sql/SQL-Introduction.html and No JOINS section, they state

  SELECT * FROM Employee WHERE city.country.name = 'Italy'

What they do not tell you at that point in the manual is that these are from linked tables and not from graph relations.

For this to work in the Graph technique, first you will need to create an edge. I would label that like locatedIn so

  Employee => `locatedIn` => City

And also edges from the City records

 City => `ofCountry` => Country

Then the graph based OrientDB query might be.

 SELECT * FROM Employee WHERE out(“locatedIn”).out(“ofCountry”) = “Italy”

You might think, this looks a lot more complicated. And it is. But just say at some point later another Edge relation named salesTerrotiryfor this employee was added by someone else then this can be Traversed and discovered like this

 TRAVERSE * FROM Employee MAXDEPTH = 2

And in there you will find that the new salesTerritory edges will be found. This is where the ad-hoc relationship discoveries to almost any depths are super easy with a Graph DB. Should you have implemented this in a relational database, you will need to explore the schema for new FKs. Doable, but a lot more complicated.

Eelworm