4 ms·
Speaking from personal experience, so YMMV, the trickiest thing about moving from a relational or document DB mindset to a graph DB mindset is remembering that
by glesica 12y ago
Speaking from personal experience, so YMMV, the trickiest thing about moving from a relational or document DB mindset to a graph DB mindset is remembering that you can store information implicitly in the structure of the graph.
So, as a very simple example, you don't have a Comment node with attributes for the person who wrote the comment and the article the comment is associated with. You just have edges pointing back to those things. Nowhere in the comment, or even in the edges, is there anything that looks like an ID or foreign key.
Unlike a document DB, however, you don't have weirdness once you have something like co-authorship. Just point to both authors, no need to duplicate the data or set up some kind of pseudo foreign key. Once you get the hang of it, it's a really elegant way to store data.
- 3pt14159 12y agoElegant to store, hell to really query. Continuing with your example of comments, it makes every query you have to do into a map reduce job, and simple fast things that used to be easy end up being a pain. Certainly useful when you really need a graph, but I don't find that it is a cure-all.
- hugofirth 12y agoI would generally agree that you should only go the graph dbms route when you actually need to. However I would attach the caveat that a lot more people need to than you might think. Almost any domain where you want to do some kind of 'deep' traversal or non trivial pattern matching is going to benefit hugely from a native graph data model.
- glesica 12y agoNot necessarily. If you have an index into the posts and you want all the comments for a given article you can find the post quickly and the comments are just one hop away from that. Beyond that it's just like SQL (order by, limit, etc.).