I was posting some comments in a related question about MVC caching and some questions about actual implementation came up. How does one implement a Model-level cache that works
There are quite a few factors to consider with caching, such as hashing, invalidation, etc. But the goal of caching is always the same: to reduce response times and resource consumption.
Here are a couple of quick thoughts off the top of my head for systems that do not use ORM:
SELECT
queries since other types affect dataserialize()
'd version of the parameters (this identifies unique queries. Seralizing parameters is not an issue because the size of parameters generally passed to select queries is usually quite trivial). Serializing isn't as expensive as you think. And because you hashed your static query concatenated with your dynamic params, you should never have to worry about collisions. INSERT
/UPDATE
/DELETE
) to rows in a model should invalidate (or set a TTL) on all items cached for that modelORDER BY
/ LIMIT
type operations in a new (modified) query rather than to pull an entire rowset from cache and manipulate it through PHP to achieve the same thing (unless there is very high latency between your web and database servers). Attempting to manage cache validation for an ORM system is a completely different beast (due to relations), and should probably be handled on a case-by-case basis (in the controller). But if you're truly concerned with performance, chances are you wouldn't be using an ORM to begin with.
UPDATE:
If you find yourself using multiple instances of the same model class within a single thread, I would suggest also potentially memcaching your instantiated model (depending on your constructor, deserializing and waking an object is sometimes more efficient than constructing an object). Once you have an intialized object (whether constructed or deserialized), it is worlds more efficient to clone()
a basic instance of an object and set its new state rather than to reconstruct an object in PHP.