While a SQL database isn't always the right tool for the job, it most definitely is the best default answer most of the time. We keep seeing these articles over and over and they keep missing the point.

This is what the author says about an e-commerce order: "But in practice, and the app almost always wants to retrieve the entire record all at one, and write the entire record all at once."

Right, because no business ever wants a total of their orders in the month?!? Or a business never wants to know who their best customers are? This is the worst example ever and proves that this "in practice" thought is entirely backwards.

Right. I love SQL, don't get me wrong, but there are a couple things my site does which SQL is just a suboptimal solution for:

1) Action caching. I stick it in memcached. This gets me free expiry-by-time, free blow-away-cache-when-deploying-new-version, and saves me having to create and maintain a table specific to caching in the database. (I really, really hate changing my schema, since I invariably manage to screw something up when migrating. Solution: don't, absent a clear need to.)

2. Caching expensive queries. Again, memcached. Much of my analytics data is publicly accessible, changes infrequently (how often am I going to add a new sale to March 2007, honestly?), and lets users calculate very expensive summary statistics. This screams "cache me!" rather than letting somebody burn my server to the ground just by opening up /stats and clicking like mad.

3. Short-term scratchpad. I have a couple of places where I need to remember little bits of information for a few minutes.

For example, a lot of customers have issues with entering registration keys, so I try to make this automatic for as many as possible. One way to do this is to have the application generate a random ID for itself, and submit this random ID to my web page when requesting the sales page. The sales page then passes this to my offsite payment processor, who will in turn pass it back with successful transactions. Meanwhile, the application polls the server periodically to see whether their ID has been associated with a purchase recently. Sure, I could stick that in the Customer table, but it feels unclean: logically, it isn't a business requirement of customers, it is just a little hack I use to make their lives easier, and it has no meaning outside of an interval which lasts, on average, about 30 seconds.

You can use memcached and an RDBMS togther, though. While RDBMSs will use memory to cache query results (with varying degrees of effectiveness), it'd be unreasonable for them to try to know about opportunities for caching e.g. generated HTML. That's really not their concern. (You may wish to look into views, though.)

The database is for searching, indexing, and ensuring that transactions are atomic. The cacheing is a different layer.