To cache the results of complicated joins (or queries without indexes).

It's pretty much pointless if all you are doing is caching the result of a simple query using an index.

Not if your database is under heavy load, and you can easily shift some of that load by putting frequently accessed things in memcached instead.

But that's clearly not true. In the most extreme case, that hash table is referenced simply by a variable in your program - it's already in your program's address-space! There's no way a database can come close to that.

    hash at: key put: anObject

The second one commits to using a relational database, one often easily triples the size of the code base. There's nothing simple about that.

Not true at all. The purpose of Memcached is to completely avoid a call to the database because the database, even if it keeps everything in memory can't touch the read speed of a distributed hash table. Memcached allows you to spread the reads across farms of boxes instead of sending them all to what is usually a single database server.

The kernel can cache the FS calls that the DB makes, but it can't cache calls to the DB!