Graph Design Question

[Eric24]

I came across a real-world example recently that seems to cry out for "normal" edges with properties (as opposed to lightweight edges): The simplified version is a list of people and the companies they have worked for. It seems to me that an edge class between person and company classes with "start date" and "end date" properties (and maybe a "reason for leaving" property) would be ideal for this. I'm still relatively new to OrientDB and graph databases in general, so I'm wondering if there is a better/preferred way to do this (or even an alternative)? I can envision a model with an "employment" vertex as well, using lightweight edges to connect people---employment---company, where the employment vertex would have the date and other properties for a given employment period. Is this "better"? Worse? Why?
--Eric

[hartmut bischoff]

Hi,

perhaps the best approach is to use the Database as a object-based tool which provides any data you need.

Then to solve the task you would first design a reliable Object-structure 

So – the first steps are not different from the RDMS-Approach.

The Questions to answer are for example:

People work in companies

Companies employ people

Companies fired people

People fired by companies

etc.

In the classic RDMS world you would consider a m:n-relation.

This implies to use bidirectional edges in orientdb.

The next step is straightforward: What attributes are necessary to describe the Relationship between People and Companies. These are the attributes for the edges.

You get the additional benefit that you don't have to know all questions to be answered (as in RDMS). You just provide some basic properties and  leave anything else to the user.

(This is just a personal suggestion, not a professional advise)

[Luigi Dell'Aquila]

Hi Eric,

for this particular use case I always prefer an Employment vertex in the middle, just because it's a good candidate to also contain additional information, and because it's also likely to have relationships with other vertices

my 2 cents

Luigi

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric24]

@Luigi: Yes, I can definitely see that. So let me ask a philosophical question: Let's say that only lightweight edges were available (i.e. OrientDB didn't even support edges with properties). Would that really be that much of a limitation?

[Luca Garulli]

Hi Eric,

OrientDB support regular edges with properties, and this is the default, but by turning on "lightweight edges", OrientDB manages things where when you don't have properties creates only 2 links instead of 2 links + record.

For more information look at: http://orientdb.com/docs/last/Lightweight-Edges.html

Best Regards,

Luca Garulli

Founder & CEO

OrientDB

[Eric Lenington]

@Luca: Yes, that's understood. My question was not about what OrientDB can do, it was really more about whether there were really any "good" reasons to ever use properties on edges. So far, every use-case I've come across where edge properties were a possible design solution, it seems like lightweight edges with additional vertices was a "better" solution. So, under the heading of "just because a product can do something doesn't mean you should use it", I was just wondering if @Luigi (or you) would consider it much of a database architecture/design limitation if OrientDB didn't support edge properties at all.

--Eric

[Riccardo Tasso]

Very good question Eric.

I guess that edges with properties were thought to be compatible with Property Graph Model (of Blueprints).

In fact you right that with a new vertex you can avoid regular (non lightweight) edges, but you have to be aware of it and handle edges by hand. For example in your use case from the first post I will suggest to regular edges unless you have to link them to something else (as Luigi said).

Cheers,

   Riccardo

[Eric Lenington]

@Riccardo: Right--of course that is the "million dollar question". In my particular example, I can easily see an "employment" vertex needing other data, so @Luigi's idea makes more sense to me (and was something I was already considering). As I learn graph databases (being a SQL guy), and OrientDB specifically, these are the kinds of things I'm trying to understand. To me, it seems like there are very few good use-cases where regular edges are best (unless you know beyond a reasonable doubt in advance that you will never need the functionality of an "interstitial" vertex). As I see it, lightweight edges with interstitial vertices are just as easy to think about and with the expense of a little more storage space, seem to be much more powerful and flexible, especially in terms of being able to add properties to the various database objects in the future as needs evolve.

You mention that you have to "handle edges by hand"; can you expand on that?

--Eric

You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/Q9zNQ8JSnVI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

[normanLinux]

I can see where everybody is coming from here, but, FWIW, I have a case where edges with properties does seem the best answer.

I have an Entity class with subclasses of Person and Business.  (Sometimes I need both types regardless, other times just people or businesses).  I need to know about relationships between these where the relationship can be almost anything.  Using a normal edge, connectedTo, with property relationship I can easily track all relationships that an individual Vertex has, with the property giving further information about the relationship.

In this particular use case I see no benefits to having a separate Vertex - or edge type - for the different types of relationsip.

Disclaimer I an pretty new to orient and still feeling my way and refining my design.  But I am really loving what it can do in the context of my (putative) application

[nagaraja sosale ramaswamy]

some other points to consider:

can the Employment vertex stand by itself without having further edges to Employee and Company? or does employment vertex exist only in context of an employee and company ?

can the employment vertex be 'reused' between other employees and companies? (my guess, not) i.e., would you be able to share an Employment Vertex for one company and a group of employees? or would you need to create an employment vertex for every pair of employee-company.

in my opinion (for this and similar use cases only), it would not be feasible to share/ reuse employment vertices (e.g., to consider what to do when employee still works for same company but nature of employment changes e.g., on-probation to permanent maybe?)

i would also not suggest to have employment vertex for each pair of employee company - it means 3 extra documents (1 vertex and 2 edges to employee and company). you could perhaps optimize that by not using edges but unidirectional links from employee to employment and company to employment but that would be sub-optimal.

it also depends on the use cases that you want to support on employee-employment-company e.g., is the use case of "employees changing companies", part of the core business processes for your application? or is

so for this use case, my design choice would be regular edge with properties. if in future the number of properties on the edge get to a point that it starts affecting the performance then i'd create another document class to hold the extended properties, and a uni-directional link from edge to the extended properties.

cheers

~nagu.