7

I'm new to NoSQL and have been playing around with a personal project on the MEAN stack (Mongo ExpressJs AngularJs NodeJs). I'm building a document editor of sorts that manages nodes of data. Each document is actually a tree.

I have a CRUD api for documents, to create new trees and a CRUD api for nodes in a given document.

Right now the documents are represented as a collection that holds everything, including nodes. The children parent relationship is done by ids. So the nodes are an map by id, and each node has references to what nodes are their children. I chose this "flat" approach because it is easier to get a node by id from a document.

Being used to having a relation table between nodes and documents, a relation table between nodes and children nodes I find it a bit weird that I have to save the entire "nodes" map each time I update a node.

Is there a better way to represent such a data type in NoSQL?

2
  • 3
    Have you read Model Tree Structures (and looked at Storing tree structures with MongoDB)? Which ones of those have you tried (if I read it right, you are looking only at the 'child reference approach')?
    – user40980
    Commented May 24, 2014 at 11:49
  • I would say I am using the child reference approach where every node holds an array of references to other nodes. My dilemma is that I have documents which can contain a lot of nodes, so having a collection of all the nodes for all the documents is not a good way to go imo. I am storing all the nodes in a hash map, like I said, in the document collection.
    – Vlad Nicula
    Commented May 24, 2014 at 11:59

2 Answers 2

Reset to default
12

You have a number of options when representing a tree structure with MongoDB. Here are five "patterns" that you could apply (link to details at the end).

  • The Child References pattern stores each tree node in a document; in addition to the tree node, document stores in an array the id(s) of the node’s children.
  • The Parent References pattern stores each tree node in a document; in addition to the tree node, the document stores the id of the node’s parent.
  • The Array of Ancestors pattern stores each tree node in a document; in addition to the tree node, document stores in an array the id(s) of the node’s ancestors or path.
  • The Materialized Paths pattern stores each tree node in a document; in addition to the tree node, document stores as a string the id(s) of the node’s ancestors or path.
  • The Nested Sets pattern stores each tree node in a document; in addition to the tree node, document stores the id of node’s parent, the node’s initial stop in the left field, and its return stop in the right field.

This tutorial in the MongoDB tutorial discusses the pros and cons of each pattern: http://docs.mongodb.org/manual/tutorial/model-tree-structures/

0

One of the tenets of NoSQL is to use the type of database best suited to the task at hand. Do you have the option to use something other than MongoDB?

For a document hierarchy, you can try something like the Java Content Repository standard. It is implemented by most major CM systems, and also has a fully conforming reference implementation: Apache Jackrabbit.

1
  • Thanks for the suggestion. Since this is a personal project I'm can consider alternatives, however mongo has good support for nodejs while the Java Content Repository seems to have little support. I did however find github.com/karacos/nocr-mongo and I'm looking at some examples now. It seems that the idea of a content repository is to provide a single root node for all the repo, while I need one root for each document...
    – Vlad Nicula
    Commented May 25, 2014 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.