为什么缓存策略不适合企业应用?

一个应用中可以有很多类型很多层次的缓存,我这里说的缓存特指memcached,因为最近在JE上看得比较多,一直心存疑惑,终于在昨天看到一片文章里面论述到企业应用一般都不使用缓存策略,我终于忍不住想问了:企业应用中同样存在大量重复的数据库read操作,命中率应该较高才对,这种情况下可以使用缓存来缓解服务器磁盘IO负担难道不是很好的办法吗?为什么说不适合呢?
虽然企业应用的重点落在业务逻辑上,在PV量和并发IP访问上可能不如互联网应用,但是类似OA和报表这样大数据量查询操作的应用中,我觉得缓存还是能立奇功的.而且因为memcached是基于对象的缓存机制,相对于数据库查询缓存来说应该在业务逻辑处理上更具优势才对,因为类似MySQL的查询缓存在表被更新以后缓存就被clear掉,这样针对写操作频繁的应用来说资源消耗将非常之大,相对来说memcached如此白利而无一害的策略为什么却被说成不适合呢?

企业应用有很多种类，比如和生产相关的系统，各种原材料，半成品，产品，库存，生产流程，订单等等信息，每时每刻都在变换，使用cache的命中率就很低

比如人力资源，文档管理系统里面用cache就很有效

这取决于你怎么设计数据库，如果表的粒度小点，不易改变的字段在放一个表，这样缓存就起作用了，其实企业应用里面变化的数据也不多

Each system, regardless enterprise level or not, has both static data and dynamic data.  Static data, of course, should be cached.  Dynamic data, can be cached or not, depending on change frequence vs read frequence.  That's the major consideration for using cache or not.  Also, data size is another concern, if it is too big.

这个我也知道 the point is如何实际量化并比较二者?

一个应用中可以有很多类型很多层次的缓存,我这里说的缓存特指memcached,因为最近在JE上看得比较多,一直心存疑惑,终于在昨天看到一片文章里面论述到企业应用一般都不使用缓存策略,我终于忍不住想问了:企业应用中同样存在大量重复的数据库read操作,命中率应该较高才对,这种情况下可以使用缓存来缓解服务器磁盘IO负担难道不是很好的办法吗?为什么说不适合呢?
虽然企业应用的重点落在业务逻辑上,在PV量和并发IP访问上可能不如互联网应用,但是类似OA和报表这样大数据量查询操作的应用中,我觉得缓存还是能立奇功的.而且因为memcached是基于对象的缓存机制,相对于数据库查询缓存来说应该在业务逻辑处理上更具优势才对,因为类似MySQL的查询缓存在表被更新以后缓存就被clear掉,这样针对写操作频繁的应用来说资源消耗将非常之大,相对来说memcached如此白利而无一害的策略为什么却被说成不适合呢?

个人认为，企业中不使用缓存，那么它软件的大数据量的信息，怎么处理？ 类时。。过多的报表信息查询，生成。。。。。。。怎办？

一般的企业用数据没这么大，我们做电信系统，都基本不用缓存的，
只是表的设计要有点技巧，比如零食表，汇总表

如果到了不用缓存实在不行的地步了,那当然会去用的.

现在不用,唯一的理由就是没到那个地步.

维护缓存并不容易呢.企业应用一般正确性要求很严格

企业级的软件一般不用新技术。
对新业务的稳定需求远大于客户感受。
一个技术至少要流行三年的后，
才敢去尝试。
与技术的好坏无关。

虚表和视图啊。