OrientDB design consideration

Question

I just strarted working with orientDB for a home project, and I'm really impressed so far. As many orient users at first I planned to have both a Mongo and a Neo instance but orient seems to be the best solution for my case.

Trouble is I have little experience with it so it makes design/schema considerations diffucult for me. This is my simplified model:

User vertex has 5 properties

Item vertex usually has around 6 properties including a large 'discription' field

I have more vertexes and plan to have a lot of edges but I was wondering, performance wise:

• Mongo generally says keep everything in one document if possible
• Neo generally says, keep your 'vertexes' light

Those two somewhat contradict, what is the best solution? I could for example store the discription in a seperate vertex so that it isnt included in every Edge or is there no performance gain in this?

BTW I know I suffer from early optimisation ;). but was just wondering.

Kr, Joris

Answer 1

Orient DB has a unique property of Object Oriented Designs where you can create a class and inherit them in classes V(Vertex) and E(Edge).You can leverage this for your store description.

Here are some of the stats about the scalability: [https://groups.google.com/forum/#!topic/orient-database/crIFYreBTdo][1]

I think you should read more about the design patterns/modelling in Graph databases, here are some links that I found useful during my project :

https://www.amazon.com/Graph-Databases-Ian-Robinson/dp/1449356265 https://www.youtube.com/watch?v=78r0MgH0u0w

Answer 2

Do not store the description in a separate vertex. There is no need.

An edge need not have any property and it certainly does not include the properties of the vertices it links.

For performance you might want to consider a 'lightweight' edge. A lightweight edge cannot have any property and does not exist as an independent entity. It is simply implemented as pointers from the two vertices to each other.