@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 <l.garu...@orientdb.com> 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 <e...@24x8.com> 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 <topo...@gmail.com>: >>> >>>> 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 orient-databa...@googlegroups.com. >>>> 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 orient-database+unsubscr...@googlegroups.com. >> 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
