关于has_many中:counter_cache的一些看法

在一对多的关系中，我对一个人，同时增加了三本书

如person.book.create(book1,book2,book3)

时，我发现日志里面

SELECT * FROM person WHERE (person.`id` = 2) 
  UPDATE products SET `book_count` = `book_count` + 1 WHERE (`id` = 2)

这样重复三次， 那如果是同时增加六本的，往上累加的话那不是很开销非常大，

如果我们把他分开来处理的话我们只要只行一次就可以了

我们计算出增加的书数量，在保存完之后再更新一下就可以了，也就是可以省下四条sql的执行

，我在想是不是这种保存方法有问题，还是有什么其他方法可以来代替

做法没问题，应该就是这样的。
如果你想只update一次，那就不要用counter_cache，而是自己来维护这个counter。

个人建议先考虑以下两个问题：
1.这种“批量”处理的机会多不多？
2.导致的性能成本高还是维护自定义代码的成本高？

如果你开发一个ajax之类的，用户体验性比较注重的话，我想这种批量处理还是比较多的，特别是在电子商务领域，我是这么看对这个问题的
1：这种批量处理的情况，在以后的应用领域来说会越来越多
2：在rails中我想可以在定义在指定关系has_one ,has_many 之关系中还可以做更多的事情，如果从counter_cache本身来说，
我的想法是在开启时通过检测是has_one还是has_many的关系来处理相应的情况会不会更好一些，这样用户就可以更好的来关心其他的一些事情。
3：对于维护成本的话我想都是差不多，主要是看你怎么构建这个东东