Get the model correct 1st. Worry about optimizing it last.... Peter Hunsberger
On Thu, Sep 17, 2015 at 12:28 AM, Nirmalya Sengupta < [email protected]> wrote: > Hello Peter, > > Many thanks for detailed reply. Great points on the importance of the > temporal nature of the relationship. You are right: my Use-Case indeed has > a time-aspect and I need to capture them in some manner. I didn't mention > them because I wanted to keep the query, simple. > > My question was driven by my concern of about growing size of the Graph. > Indeed, if a relationship has served it purpose and we are unlikely to use > it ever again, we may want to remove it, may we not? We want to *prune* > the Graph of *unnecessary* *relations*. If that is so, how does one do > that in Neo4j using Java APIs (I have seen examples of achieving the same > using Cypher but at the moment, our software is primarily using Java APIs)? > > Will appreciate your views on this. > > -- Nirmalya > > On Thursday, September 17, 2015 at 6:47:14 AM UTC+5:30, Peter Hunsberger > wrote: >> >> Once a relationship is deleted then you have no historical reporting >> capabilities unless you'r managing that somewhere else.... >> >> I don't know about your use case but typically these kinds of >> relationships have a time frame associated with them. Given that a ship >> may in fact be moving away from it's destination at a minimum I'd use a >> Destination relationship with departure date and arrival date attributes on >> the Destination relationship. However, if you ever want to report on >> trips between certain time periods then the dates might become first class >> nodes. In that case you might want to introduce trips as first class nodes >> and have them liked to destinations and departure and arrival dates >> >> <ship1> -- Traveled --> <trip1> -- Destination --> <port1> >> .......................................+ -- Departure--> <date1> >> .......................................+ -- Arrival --> <date2> >> >> You have to watch out for dates becoming super nodes but this is very >> generally useful. You can then also start to collect things like >> "scheduled arrival" on the trip or break the trip into segments or legs >> each with their own set of dates etc. >> >> Peter Hunsberger >> >> On Wed, Sep 16, 2015 at 10:14 AM, Nirmalya Sengupta < >> [email protected]> wrote: >> >>> Hello all, >>> >>> I am trying to understand how to model use-cases which require removal >>> of a Relationship between two nodes. >>> >>> Let's say that, we are capturing the current destination of a ship to a >>> port. >>> >>> <ship1> --- MovingTowards --> <port1> >>> >>> After some time, *ship1* reaches *port1*, unloads cargo, loads new >>> cargo and then sails for *port2*. The latest snapshot of the Graph >>> should indicate that clearly. >>> >>> To capture this correctly, I think I should remove the current >>> relationship between *ship1* and *port1* and add a new relationship >>> between *ship1* and *port2* >>> >>> <ship1> --- Moving *'X'* Towards --> <port1>, and >>> <ship1> --- MovingTowards --> <port2> >>> >>> How do I achieve this using Java APIs? Is this even the right approach? >>> If now, what should be? >>> >>> -- Nirmalya >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" 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 > "Neo4j" 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 "Neo4j" 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.
