You're still missing the point. Joins and sorting and grouping in SQL are what you use to populate the real data structures. Whether you know it or not, in all but the most simplistic CRUD application, you've gotta write code to deal with all of those data structures. The database is always in addition to that complexity. The argument being made is that you can leave out the database entirely in some environments, and not add that complexity.

The entirety of this thread is questioning the pervasive use of databases in web applications. There are some where it makes excellent sense (accounting, CRM, ERP, the stuff that's been the strong-hold of Oracle and SAS for years). And others (wikis, blogs, forums, photo galleries, etc.) where it may not make good sense, because you introduce hundreds of unnecessary operations and significant additional database support code. That's not to say a database is never the right solution for these problems (when your problem starts looking relational, you should start looking at relational databases, because your Ruby or Python or Lisp implementation is going to be worse than what PostgreSQL or MySQL have). And, as someone else mentioned (but got modded down)...when you start building your own flaky transactional layer, then it may be time to consider a database that has good transactions support.