With my background in SQL (relational) databases, I have been struggling to figure out how to create related objects in NoSQL stores. In my recent projects, using mongoDB, I have been relying on the ability to do queries and using familiar relational techniques as described in Data Modeling Introduction - mongoDB.
After reading up on Firebase based on the recent topic Firebase Joins Google, I came across an excellent tutorial on another way to structure data in the world of NoSQL stores, Structuring Data - Firebase, that really synchronized with me.
While this may be old news to those who have been using NoSQL stores for some time, I found it particularly helpful for me (a dinosaur still trying to figure out why I should be using a NoSQL store).
I've found that trying to trick my mind out of the relational model was made easier after my transition to using Code First in Entity Framework. When I stopped thinking about my data and just started to think of it as an object model things just sort of clicked. I think there is time for relational data and time for object data. They both make sense for different parts of an app. Thanks for the article btw.
Object stores like mongo may seem strange at first but once you get into the mindset @aaron touches on, where your data is really just reflective of JSON.
In many cases, the necessity for a variety of multiple tables just doesn't exist with something like Mongo -- why should a blog post and its comments really be separated? Shouldn't they be part of the same object?
"title": "My post",
"content": "Thanks Obama!",
That's the fun part about Mongo, IMO is you realize that you have the freedom to structure data naturally rather than using associative, linking tables.
The other thing about MongoDB is, in my experience, it's far more pleasurable to code with when using an ODM. For NodeJS and MongoDB, the standard go-to is Mongoose. Using an ODM allows you to define schema, validation, and other goodies to act as an abstraction between you and the potential chaos of NoSQL.
Here is a pretty good article on "Reactive Joins in Meteor" that might add some more perspective to relationships in NoSQL in General.
In Meteor it's actually recommended to not nest so deeply also because of how it get's the data using "Publications and Subscriptions"