… graph databases focus on the relationships between items â€” a better fit for highly interconnected data models.
Standard SQL cannot query transitive relationships, i.e. variable-length chains of joins which continue until some condition is reached. Graph databases, on the other hand, are optimised precisely for this kind of data. Look out for these symptoms indicating that your data would better fit into a graph model:
- you find yourself writing long chains of joins (join table A to B, B to C, C to D) in your queries;
- you are writing loops of queries in your application in order to follow a chain of relationships (particularly when you donâ€™t know in advance how long that chain is going to be);
- you have lots of many-to-many joins or tree-like data structures;
- your data is already in a graph form (e.g. information about who is friends with whom in a social network).
Graph databases are often associated with the semantic web and RDF datastores, which is one of the applications they are used for. I actually believe that many other applicationsâ€™ data would also be well represented in graphs. However, as before, donâ€™t try to force data into a graph if it fits better into tables or documents.
In our experience, particularly social applications or applications that deal with complex interrelated data are much easier to build using a graph of typed objects in InfoGrid than to shoehorn into relational tables. But then, InfoGrid can use relational databases as storage engines, so we have the best of both worlds: graphs on the front, and enterprise-friendly SQL on the back.