MongoDB: What about recursive data

Question

EDIT: I edited the question and separated the "MongoDB: Replicate data in documents vs. "join"" part into this topic on https://softwareengineering.stackexchange.com/

I have already played a bit with the mongoDB aggregation framework building some dummy queries and seeing the potential of the pipelining, the sub-documents structures in order to avoid the traditional SQL JOINs and so on.

Also, I've already read about when to use a document-oriented data base, checked out some MongoDB production deployments and use cases examples, and realized that the Oracle nested tables isn't a real alternative in terms of performance vs MongoDB.

I've also checked out the Diaspora MongoDB use case, in which they explains about the recursive data problem, an evidence that the graph data bases would fit better for that kind of scenarios:

Finally, and in order to structure all of these information in my used-to-be-normalized-head, I want to know what do you think about the following conclusions:

1. If you have recursive data (like in the Diaspora example), you should go with graph databases like neo4j.
2. Replicate data in each document vs. "join" example: Question separated into this one.

Thanks!

Answer 1

If you have recursive data (like in the Diaspora example), you should go with graph databases like Neo4j.

If you have data that is connected, that doesn't conform to a hierarchical model, you're looking for a Graph Database.

Take a look at the Diaspora example modeled as a Neo4j GraphGist.

Social Network Graph Example from Diaspora

This is a very "graphy" data structure. A commenter is a user, and a friend is a user, and a liker is a user.

A graph database simplifies this data structure to the following:

Which is easily queried using Cypher.

MATCH (u:User)-[:FRIEND]-(f)-[:POSTED]->(post) 
WHERE u.name = "Rachel Green" 
RETURN f.name AS friend, post.text AS content

When your data looks like this:

It's probably a good idea to go with a graph database.