0

There is no "right way" to do anything, but there are "better" and "worse" ways, as well as true and tested ways.

I'm studying Mongo and considering it for a project. It's gonna start small but possibly grow a lot.

Now, I understand there are different ways to organize information in MongoDB. Since there are no joins, I either insert ids (Or arrays) and do multiple queries to get a related item (I.e. person for a company, company Id on people object or array of people on company table), or I insert objects directly inside... (I.e., people as objects in an array inside the company, as opposed to being "decoupled").

Now, my issue is: what if I need to change how I load this info?

A good example, taking the users idea, is if I wanna get all people (Of all companies) inactive for the last month. Now, would I need to look separately into one company at a time to query this information? Should I keep them separate and use ids as references in this case...?

What are the tradeoffs, the performance impacts, and which approach is considered "more appropriate" by the community?

  • You may find you'll have to store the same data in multiple ways and very complex querying will need to be done in your app and not the database. – JeffO Mar 19 '15 at 20:51
  • JeffO, do you mean the standard way is to duplicate data (In the interest of fast-accessing it)? I'm not worried about having the relationships' "logistics" in the app, I'm mostly interested in learning the standard, the most performatic and the frowned upon ways to store data and work with it. It's more of a conceptual question about mongodb and what it means to work with it, as opposed to simply comparing it with sql databases, which is error-inducing, imho. – Fernando Cordeiro Mar 19 '15 at 23:34
1

As noted by John F. Miller on another question at SO (https://stackoverflow.com/a/5373969/1793074), MongoDB is great at nesting data, but not so grat to search this nested data.

Another great resource on this matter comes from the same answer: http://seanhess.github.io/2012/02/01/mongodb_relational.html

Basically, you relinquish control when you work with "documents inside documents". A lot of controle.

With that said, the suggested approach is to only insert a document inside another if the "inside-document" is absolutelly dependant on the outside one. Then, and only then, you can "skip collections".

You can, though, insert objects that reference other collections, using denormalization techniques to have performance gains.

What to choose is up to each project, but for data that has to be queried and used in different situations, the best is to have separate collections, and reference by id or dennormalizing for faster access.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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