Anti-patterns for Neo4j: Where RDBMS win over graph databases


The biggest gotcha we both found when moving from RDBMS to graphs some years back (when we were users of early Neo4j versions, way before we were developers on the product) was the years of entrenched learning of relational modelling. We found it difficult to leave behind the design process of creating a normalized model and then denormalizing it for performance — we didn’t feel like we’d worked hard enough with the graph to be successful.


It was agonizing in a way. You’d finish up some piece of work quickly and the model would be performant and high fidelity, then you’d spend ages worrying that you’d missed something.

Fortunately today there are materials to help get people off the ground far more quickly. There are good books, blog posts, Google groups and a healthy meetup community all focussed around graphs and Neo4j. That sense of not working hard enough is quickly dispelled once you’ve gotten involved with graphs and you get on the real work of modelling and querying your domain — the data model gets out of the way, which is as it should be.

DZone

Comments

Popular posts from this blog

Tuning ext4 for performance with emphasis on SSD usage

Java 8: Default Interface Implementations, The Diamond Problem, Multiple Inheritance, and Precedence

Tuning ext3 for performance without losing its data integrity potential