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