@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] > <javascript:>>: > >> 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] <javascript:>. >> 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.
