I was looking at:
Now that I am at the intermediate level with Graph DB's, I'm wondering from a (pedagogical point of view) if/when it would be a good time to introduce some higher level concepts (or maybe hint at them.). Perhaps on another page?
For example, a DB designer might want to add Genres to the Movie DB. That would make the DB much richer. One could do that with a property. However, it can be awkward if you have a Movie like "Aliens" which is SciFi, Horror, and Action. But you can solve this problem by give a Movie node multiple Labels. (a lot of newbies don't realize you can give Nodes multiple Labels.)
The other hidden advantage of Labels, is they are in implicit index for Nodes. Now, once the Movie Nodes is have Genre labels, the are quickly accessible in a query such as:
MATCH(movie:Scifi) <-[:ACTED_IN]-(p:Person)
This shows off the power and flexibility of Neo4J in that you can make a significant change to the DB without having to do a DB migration or formal Schema Change. Also, the power of Neo4J to model many-to-many relationships (which is a major pain point for "Relational" DBs).
On the other hand, this would be a good time to indicate when it would be potentially a bad idea to have multiple nodes. You could add Actor, Writer, Director, etc. labels to Person. But then, if an Actor as a new venture decides to direct her first movie, her node would not automatically have the Director label. Such a DB design would be in danger of being inconsistent, if you didn't remember to update the Person node. (I believe that could be fixed with a Trigger.)
You could also show that to get all actors you could make the query:
MATCH (p:Person)-[:ACTED_IN]->()
Another point to make, is that Relationships cannot have more than one Label.
Other interesting queries to show off:
- Persons who are actors/directors/writers
- Persons who are only actors (trickier, since that requires a negation.)
