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. On Saturday, August 1, 2015 at 4:13:26 PM UTC+5:30, normanLinux wrote: > > 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 > > On Friday, 31 July 2015 20:57:31 UTC+1, Eric24 wrote: >> >> @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 >> >> >> On Fri, Jul 31, 2015 at 2:37 PM, Riccardo Tasso <[email protected]> >> wrote: >> >>> 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 >>> >>> 2015-07-31 18:26 GMT+02:00 Eric Lenington <[email protected]>: >>> >>>> @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 >>>> >>>> >>>> On Fri, Jul 31, 2015 at 11:21 AM, Luca Garulli <[email protected]> >>>> wrote: >>>> >>>>> 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 <http://orientdb.com/> >>>>> >>>>> >>>>> On 31 July 2015 at 18:16, Eric24 <[email protected]> wrote: >>>>> >>>>>> @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? >>>>>> >>>>>> On Friday, July 31, 2015 at 4:45:56 AM UTC-5, Luigi Dell'Aquila wrote: >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> 2015-07-31 11:34 GMT+02:00 hartmut bischoff <[email protected]>: >>>>>>> >>>>>>>> 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) >>>>>>>> >>>>>>>> >>>>>>>> On Friday, July 31, 2015 at 1:51:18 AM UTC+2, Eric24 wrote: >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>> >>>>>>>> --- >>>>>>>> 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 [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> >>>>>> --- >>>>>> 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 [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> -- >>>> >>>> --- >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> >>> --- >>> 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 >>> [email protected]. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
