A little doubt about the inverse three paradigms of the data table?

A simple question:

Article Classification table:

article_type(id, name, pid, num)

This num is the number of articles in this category, which I've been doing before, updating the fields of the corresponding categories when adding articles or deleting articles num .

But now I feel that this seems unnecessary, because each article category below the number of articles can be easily calculated through the article table count() , so I think this num is superfluous, and edit the article operation also need to update the article_type table num feel a little annoyed.

I want to cancel this field, but it is very tangled, because, so the relative select statements will increase, before directly from the num line, and now every time, count() how many categories will be count() a few, the feeling is not relative to the previous performance problems, not too reasonable?

It feels like a simple question about the coupling of programs, the paradigm design of tables, and so on.

Tangled, hope the great God guidance, thank you!

Reply content:

A simple question:

Article Classification table:

article_type(id, name, pid, num)

This num is the number of articles in this category, which I've been doing before, updating the fields of the corresponding categories when adding articles or deleting articles num .

But now I feel that this seems unnecessary, because each article category below the number of articles can be easily calculated through the article table count() , so I think this num is superfluous, and edit the article operation also need to update the article_type table num feel a little annoyed.

I want to cancel this field, but it is very tangled, because, so the relative select statements will increase, before directly from the num line, and now every time, count() how many categories will be count() a few, the feeling is not relative to the previous performance problems, not too reasonable?

It feels like a simple question about the coupling of programs, the paradigm design of tables, and so on.

Tangled, hope the great God guidance, thank you!

First, the design is in accordance with the paradigm, which means that you design the table in the original intention is as little redundancy.
Second, due to the appropriate inverse paradigm, the strict paradigm in a particular situation leads to a serious performance impact, which means that you need to weigh the "elegant design" with the "pragmatism", which needs to be based on the difference in your business and never pursue perfection.

Now look at your scenario, your article_type adds Num redundancy, and in this scenario, the benefit is that when the article's W is more, and your real-time requirements for each type of num are not so high, you need to show them frequently in multiple places, Even if you are updating every day or every hour, the redundancy of NUM is reasonable, and you may reduce the need for the Select COUNT (*) process. But when you only have a very small number of places that require this num, then count will meet your requirements and will not give you a visible performance penalty, in which case you should follow the paradigm.

Considering giving up using NUM can give you most of the hassle of refactoring the code how much? Will it affect the core logic? Is it possible to get num to the cache?

