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