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
Databases are vastly more complicated and require me to completely disassembly the object graph anObject may contain into a set of tables and rows to store it, and then reassemble the graph from tables and rows back into their object form when fetching.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.
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.