关于数据表反三范式的一点疑问？

一个简单的问题：

文章分类表：

article_type(id, name, pid, num)

这个num是该分类下的文章数量，我之前一直就是这样的，在新增文章或者删除文章时都会更新对应分类的num字段。

但是现在我觉的这好像没有必要，因为每个文章分类下面的文章数量可以通过文章表很容易的count()算出来，所以就觉得这个num是多余的了，并且编辑文章操作时还要更新article_type表num感觉有点烦。

我想取消这个字段，但是又很纠结，因为，这样以后相对的select语句会增多，以前直接从num取就行了，现在每次都要count()一下，有多少个分类就要count()几下，感觉是不是相对于以前而言有性能问题，不太合理呢？

感觉就这么个简单的问题就已经涉及程序的耦合，表的范式设计等考量。

纠结，希望大神指点，谢谢！

回复内容：

一个简单的问题：

文章分类表：

article_type(id, name, pid, num)

这个num是该分类下的文章数量，我之前一直就是这样的，在新增文章或者删除文章时都会更新对应分类的num字段。

但是现在我觉的这好像没有必要，因为每个文章分类下面的文章数量可以通过文章表很容易的count()算出来，所以就觉得这个num是多余的了，并且编辑文章操作时还要更新article_type表num感觉有点烦。

我想取消这个字段，但是又很纠结，因为，这样以后相对的select语句会增多，以前直接从num取就行了，现在每次都要count()一下，有多少个分类就要count()几下，感觉是不是相对于以前而言有性能问题，不太合理呢？

感觉就这么个简单的问题就已经涉及程序的耦合，表的范式设计等考量。

纠结，希望大神指点，谢谢！

第一，设计是遵守范式的，这代表你在设计表的初衷是尽可能少的冗余．
第二，适当的反范式，特定的场合下严格的范式反而导致严重的性能影响，这意味着你需要在＂优雅的设计＂和＂实用主义＂之间做权衡，这一点需要根据你业务的不同来看，永远不要追求完美．

现在来看看你的场景，你的article_type增加了num的冗余，这种场景下，能带给你好处的是，当文章的w比较多，而你对每一类的num的实时性要求并不是那么高，但你又需要频繁的在多处显示，甚至你可能是每天或者每个小时更新一下，这时候num的冗余是合理的，你可能会减少需要select count(*)的过程．但当你只有只有很少的地方需要这个num，那么count完全能满足你的要求，而且不会带给你看得见的性能损失，这种情况下，应该要遵守范式．

考虑放弃使用num能带给你大多的麻烦，需要重构的代码多么？会不会影响到核心的逻辑？是否可以把num做到cache中去呢？