The comparison was vs keeping stuff in a hash table in memory, and I was saying databases are no worse.
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.
Not to mention that you can hash arbitrary objects in a hash table with no mapping of any kind.
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.
> To cache the results of complicated joins (or queries without indexes).
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.