[Neo] Modelling advice

Michael Hunger neo at jexp.de
Fri Sep 26 08:12:32 CEST 2008

Isn't that the general approach when adding information to relationships?
It's common in ER to introduce mapping tables that not only contain the
foreign key references but also data as well.
In OO its the same.
Fortunately most of the time the newly introduced relationship type will
evolve quickly into a important member of the business domain with even more
relevant data and behaviour.


Qualified Relationships have also been introduced to qi4j.
Emil Eifrem schrieb:
> On Fri, Sep 26, 2008 at 12:37 AM, Jonny Wray <jwray.develop at gmail.com> wrote:
>> Hi,
>> I'm in the process of moving an application over from an RDF based graph
>> store to Neo. So far it's being great but I'm currently hitting a modelling
>> question that I'm sure some experience with the technology would help, and
>> so I'm asking the group.
> Hi Jonny,
> I *think* I understand your problem and basically the solution will be
> depending on the complexity of the evidence data. If it's fairly
> complex, I think injecting a middle node will be the best way. So when
> node1 is SIMILAR related (just making this up) to node2, then instead
> of the obvious:
>    ( node1 ) -- SIMILAR --> ( node2 )
> you would model it like this:
>    ( node1 ) -- SIMILAR --> ( node14 ) -- SIMILAR --> ( node2 )
> Node 14 in this diagram is the middle node, and you an attach whatever
> information you want to it, either in the form of properties or for
> example separate evidence nodes that aggregate data for a single piece
> of evidence and that attach to node14 through e.g. a
> But if your evidence data is simple enough, it may be enough to just
> connect the nodes with a relationship and then add the data as
> key-encoded properties. For example:
>    ( node1 ) -- SIMILAR --> ( node2 )
> And then on the relationship, you would have properties like:
>    evidence1.origin = something
>    evidence1.weight = 0.8f
>    evidence2.origin = somethingelse
>    evidence2.weight = 0.4f
> The advantage with the middle node design is that the node space
> layout in a sense is more clean and flexible. But it loses out on
> intuition and "white-board friendliness."
> The advantage with the second layout is that it's the intuitive and
> obvious way to model this data. It also keeps the number of primitives
> down. The disadvantage is that it's brittle to encode information in
> the names of the property keys. (How do you delete one piece of
> evidence? Gotta loop through all keys and do string matching. Yuk!)
> Which one is the better choice I believe comes down to personal
> preference and the specifics of the actual domain.
> Does that make sense or did I misunderstand the use case?
> Cheers,

Michael Hunger
Independent Consultant

Web: http://www.jexp.de
Email: michael.hunger at jexp.de

Enthusiastic Evangelist for Better Software Development

Don't stop where you are: http://creating.passionate-developers.org
We support Software Engineering Radio (www.se-radio.net)

More information about the User mailing list