counter_cache as an optimization step
I had a debate with a programmer friend of mine once about optimization. I argued that once you get past adding indexes to a relational database, every attempt at increasing its speed or scaling is an act of denormalization. Whether its double storing information in the database in such a way that it can be read more efficiently by different queries or its adding in a cacheing layer—be it key-value-esque or page/fragment caching your view layer—it’s all essentially doing the same thing: making your DBA’s head explode
Comments
So we should not use caching so the DBA’s head stays cool? Good idea … NOT!
Post a comment