Meteor denormalizes

Denormalized

Denormalized data does not store normalized data. In other words, denormalization means that multiple copies of the same data exist at the same time.

In the previous chapter, we've not normalized the total number of comments in a post to avoid loading all the comments every time. This is redundant in the sense of data modeling because we can calculate the total at any time by counting each comment (when running speed is not taken into account).

Denormalization usually means additional development work. I n the example, each time we add or delete a comment, we also need to update the relevant posts at the same time to commentsCount field remains accurate. That's why relationship databases, such as MySQL, don't take this for granted.

However, normalization also has its commentsCount as we did at the beginning, and in order to calculate the total number of comments, each time we need to transfer all the comments. Denormalization allows us to avoid this situation entirely.

A special release

We can create a special post that sends out the number of comments we're interested in (we can see the number of comments on the post right now through the aggregate query server).

If the complexity of publishing code like this is no more difficult than that caused by denormalization, it is worth considering...

Of course, this consideration is application-related: if you write code that is important for data integrity, avoiding data inseavity is more important and more important than performance improvements.

Embed files or use multiple collections

If you have Mongo experience, you may be surprised that we created a separate second collection of comments: why not embed comments directly in the post document?

It turns out that many of the tools Mongo provides give us better results when it comes to collection operations. For example:

1. {{#each}} collection.find() is very effective. But when it traverses an array of objects in a larger file, it is inefficient.
2. allow and deny at the document document level, so it's easy to make sure that each comment is correct, but it gets more complicated at the post level.
3. The DDP operates at the top-level property level of the document———— which means that if post of the comment the server sends the entire updated list of comments for the post to each connected client each time a new comment is created on the post.
4. It is easier to control publishing and subscriptions at the document level. For example, we want to page comments on a post, and if the comments don't belong to their own collection, we'll find it hard to do.

Mongo recommends embedding documents to reduce the number of expensive queries. However, given Meteor's architecture, this is not a problem: most of the time we query the client for comments, and its database access is virtually no.

The disadvantage of denormalization

There are also good reasons why you don't denormalize your data. To better understand the opposition to denormalization, we recommend reading Sarah Mei's why you shouldn't use MongoDB.