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.
