1

This question has been driving me crazy and I can't get my head around it. I come from a MySQL relational background and have been using Meteorjs and Mongo. For the purposes of this question take the example of posts and authors. One Author to Many Posts. I have come up with two ways in which to do this:

  1. Have a single collection of posts - Each post has the author information embedded into the document. This of course leads to denormalization and issues such as if the author name changes how do you keep the data correct.

  2. Have two collections: posts and authors - Each post has an author ID which references the authors collection. I then attempt to do a "join" on a non relational database while trying to maintain reactivity.

It seems to me with MongoDB degrees of denormalization is acceptable and I am tempted to embed as implementing joins really does feel like going against the ideals of Mongo.

Can anyone shed any light on what is the right approach especially in terms of wanting my app data to scale well and be manageable?

Thanks

Dylan Scott
  • 468
  • 2
  • 8
  • http://docs.mongodb.org/manual/core/data-modeling-introduction/ – 1321941 Jan 22 '15 at 18:19
  • See my answer to [this question](http://stackoverflow.com/questions/25344444/best-model-for-representing-many-to-many-relationships-with-attributes-in-mongod). – David Weldon Jan 22 '15 at 19:03

1 Answers1

3

Denormalisation is useful when you're scaling your application and you notice that some queries are taking too much time to complete. I also noticed that most Mongodb developers tend to forget about data normalisation but that's another topic.

Some developers say things like: "Don't use observe and observeChanges because it's slow". We're building real-time applications so that a normal thing to happen, it's a CPU intensive app design.

In my opinion, you should always aim for a normalised database design and then you have to decide, try and test which fields, that duplicated/denormalised, could improve your app's performance. Example: You remove 1 query per user. The UI need an extra field and it's fast to duplicated it, etc.

With the denormalisation you've an extra price to pay. You've to update the denormalised fields according to the main collection.

Example: Let's say that you Authors and Articles collections. On each article you have the author name. The author might change his name. With a normalised scenario, it works fine. With a denormalised scenario you have to update the Author document name AND every single article, owned by this author, with the new name.

Keeping a normalised design makes you life easier but denormalisation, eventually, becomes necessary.

From a MeteorJs perspective: With the normalised scenario you're sending data from 2 Collections to the client. With the denormalised scenario, you only send 1 collection. You can also reactively join on the server and send 1 collection to the client, although it increases the RAM usage because of MergeBox on the server.

Denormalisation is something that it's very specify for you application needs. You can use Kadira to find ways of making your application faster. The database design is only 1 factor out of many that you play with when trying to improve performance.

Mário
  • 1,603
  • 14
  • 24