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 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.
