Hi Fatih, Most social networks currently support relatively shallow graphs - "friend-of-a-friend" and "follow" for instance. In those situations, it's an OK solution to have information in your stored documents/values/columns that tells indicates that shallow relation.
At runtime, the application software that binds to the database creates the graph by following these logical clues. Since the graphs are shallow, it can work but it bakes in a very specific graph topology into your database and application layer which implies tight coupling. FlockDB from Twitter I think exemplifies this - a very specific use case for shallow graphs that suits Twitter really well. A graph database takes a different approach: it stores graphs of any depth in a way that doesn't compromise flexibility or performance, nor does it imply a tight coupling. For example, I might start off an e-commerce application with just people and relationships to items they have bought. Then over time I can add functionality to perform recommendations by looking for specific patterns in a graph. E.g. people who we think are young fathers (they buy nappies and they buy beer) often buy games consoles - it's now easy to look for that pattern in the graph to see possible customers who fall into the young father category and who haven't yet bought a games console and recommend that they buy one. This is am emergent property of graphs. Store all the relations you like in Neo4j and perhaps later on you'll be able to do some graph analysis to extract useful business information that you can't even think of today. If you go down the KV store path for this, you will design your graph far too early and lose the ability to do arbitrary business intelligence on your data. That's why graphs are cool - they allow you to defer such decisions to a more responsible moment. Jim _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
