Advise for having path aware properties

[Serkan]

Hi,

Could you please advise me how to keep properties of relations and
nodes which depends on their ancestors? To make it easier to
understand let me give you an example. Let's say I have a graph which
consists of car parts as nodes and those nodes are connected to each
other with "has" relationships. So a simple example of such a graph
would be like:

chassis ---> door ---> window

Now I want to add 2 car models to this graph as root nodes. Those two
models are connected to the same node:chassis.

model1 ---> chassis
model2 ---> chassis

Let's say model1 has 4 doors and model2 has 2. How can I express this
best? Should I save it as a property of model nodes? Can I somehow
store it as a property of relationship (such as count) between chassis
and door but keep different values for different models? Or should I
replicate the common nodes for each model?

Many thanks
Serkan

[Peter Neubauer]

Serkan,
I would probably model it like this: Have a relationship type per
model and then just connect the parts, having the number on the
relationship, example at

http://bit.ly/InUkDn

Would that work?

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

Neo4j                                - Graphs rule.
Program or be programmed - Computer Literacy for kids.
http://foocafe.org/#CoderDojo

[Serkan]

Thanks Peter,

I guess that would work.
Actually that was something I thought but I was not sure if it would
create performance issues when the number of models increases. If n
models can be represented by n*m relationships, adding 1 model to the
graph will increase the relationships by m.
I had the impression of this is not how this db is designed, so it
might create performance issues. Do you think it is ok to construct
graphs this way: with a lot of relationship types (say thousands)?

Thanks a lot
Serkan

On Apr 14, 10:02 pm, Peter Neubauer <peter.neuba...@neotechnology.com>
wrote:

> Serkan,
> I would probably model it like this: Have a relationship type per
> model and then just connect the parts, having the number on the
> relationship, example at
>
> http://bit.ly/InUkDn
>
> Would that work?
>
> Cheers,
>
> /peter neubauer
>
> G:  neubauer.peter
> S:  peter.neubauer
> P:  +46 704 106975
> L:   http://www.linkedin.com/in/neubauer
> T:   @peterneubauer
>
> Neo4j                                - Graphs rule.

> Program or be programmed - Computer Literacy for kids.http://foocafe.org/#CoderDojo

[Mattias Persson]

2012/4/15 Serkan <mse...@gmail.com>

Thanks Peter,

I guess that would work.
Actually that was something I thought but I was not sure if it would
create performance issues when the number of models increases. If n
models can be represented by n*m relationships, adding 1 model to the
graph will increase the relationships by m.
I had the impression of this is not how this db is designed, so it
might create performance issues. Do you think it is ok to construct
graphs this way: with a lot of relationship types (say thousands)?

You can have up to 32k relationship types at the moment, so it might not scale if the number of parts grow too much. I'd suggest having that as properties in the relationships, with perhaps as fine grained relationhip types as possible, but not per part. The number of relationships per node isn't going to be that high is it?
 

--
Mattias Persson, [mat...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

[Serkan]

Hi Mattias,

In that case number of relationships per node will be very small
indeed (around 10) but number of properties for relationships will be
too many. For every model, I will need to keep a set of properties at
each relation that model is connected to. Is there an explicit or
implicit (imposed by performance) limit to the number of properties a
relationship have?

Thanks
Serkan

On Apr 16, 1:56 pm, Mattias Persson <matt...@neotechnology.com> wrote:
> 2012/4/15 Serkan <mser...@gmail.com>

> Mattias Persson, [matt...@neotechnology.com]
> Hacker, Neo Technologywww.neotechnology.com

[Mattias Persson]

There isn't a hard limit, but if you've got thousands of properties it'll take longer to load them (since all are loaded if any is requested) the first time.

Could you give an example of which properties each relationship would have?

2012/4/16 Serkan <mse...@gmail.com>

[Serkan]

Hi Mattias,

The example I gave is not the real domain I am working on. I chose it
to explain what I need in a simple way. What I actually need to model
are surveys. In short, surveys are made of questions and answers.
Answers are shared between questions and questions are shared between
surveys. So what I have in mind is to define questions and answers as
nodes and link them together using relationships. To define a new
survey, I will add a survey node and link it to the relevant question
nodes. Those links will have several properties like the order of
display (i.e. which question/answer will be displayed first). And
these can change from survey to survey. Also some surveys might not
want to display some answers of the question.
And I can say that there will be thousands of surveys in time.
What do you think, is neo4j good choice to hold such a graph?

Regards
Serkan

On Apr 16, 3:29 pm, Mattias Persson <matt...@neotechnology.com> wrote:
> There isn't a hard limit, but if you've got thousands of properties it'll
> take longer to load them (since all are loaded if any is requested) the
> first time.
>
> Could you give an example of which properties each relationship would have?
>

> 2012/4/16 Serkan <mser...@gmail.com>

> Mattias Persson, [matt...@neotechnology.com]
> Hacker, Neo Technologywww.neotechnology.com

[Craig Taverner]

I think Neo4j works well here. You just need a node for the 'instance' of a question in a survey. So if you have a question that can occur in 5 surveys, then you should have five nodes for that, each connected to the one question and to each of the five surveys. Think of this as a kind of join-table, but it is actually much more natural in the graph.

The same thing can be done for the answers, since now each answer really belongs to one particular instance of a survey, the instance answered by one particular participant. So that participants answers will probably be collected together in a survey instance, but each answer also connected to the original question and original survey.

[Serkan]

In that case there will be a lot of nodes. But hey, Neo4j should be
designed to cope with that. So, I think that's a good idea.
Thanks a lot Craig.

Cheers

[Craig Taverner]

You're welcome.

Yes, Neo4j does well with lots of nodes and relationships. One thing to keep in mind though, is that lots of nodes and relations do lead to very large database sizes on disk, which also takes longer to write. If you are doing very large bulk loads up-front this can be an issue, but if the database is being built over time, the benefits of easier/faster queries certainly outweigh any disadvantages of disk usage.

Although I must admit, I do not really see surveys as being very large. Not of the order of hundreds of millions of nodes, I'm sure.