Reputation: 16515
I am learning graph databases (Neo4j to be specific) and I chose to model the game Ticket to Ride. The game consists of each player connecting cities to each other. Some cities have two paths, maybe with different colors, between them. For example, to go from New York to Boston, you can choose to spend two red or two yellow cards. From Montreal to Boston, there are two paths, but they accept any colors, and from Montreal to New York, you can only spend 3 blue cards.
(source: daysofwonder.com)
The kinds of questions I need to answer are:
My question is: should the routes / segments between cities be nodes, or should they be relationships? I can see it both ways. Are there advantages to making them nodes, rather than relationships?
The only property I need to remember on a route is what player owns the route, or some sentinel value (distinct from NULL) to indicate a route is yet unowned.
Upvotes: 2
Views: 1596
Reputation: 1617
One of the rules I often ask myself when taking this decision is: Will I need, or improve things, if I make it a node, that is: with a node I can connect other relationships to it. You mention that you need to relate a user or owner to that relationship, well in that case it's a good candidate for a node (to represent your routes
(Boston:Place)-[:route]->(x:Route)-[:route]->(Montreal:Place)
Here using labels if on Neo4j 2.0+
Also note that if you need to search for routes belonging to someone, it would be much faster with with it as a relationship, then building it into indexing as I would think that you might have many, many routes at some point, thus making it quite a huge index, but i could be wrong on that point, however it bares consideration.
As for longest and shortest, you can always use the
shortestPath((n1:Place)-[r:route:*..]-(n2:Place))
to exclude, have a look at WHERE clause as you can most likely do WHERE r <> something.
Upvotes: 4