In the good old times, when sky was more blue and trees were taller, there was two almost distinct approaches to use SQL database. They call them OLTP and Data Warehouse. Some vendors, such as Informix or IBM even offered a different products for those two segments. The firs one, as one can understand from its name, is about fast and reliable online transaction processing, which means triggers and stored procedures and loads of small queries, mostly inserts or updates. Now all those no-fsync options and noSQL and mem-caching solutions solve similar problems their own way. You can have a thousands of writes and, if your system never crashes, with some data consistency (and forget about triggers) In old good times Informix Dynamic Server was the answer.

Data Warehousing is all about JOINS, big JOINS. Or that thing they call it data-cubes. In that case you need query optimizer, lot and lots of buffers, data partitioning and several layers of caches. You also should use stored procedures, because it is a good way to structure and manage your code, same way modules work for other languages. So, you know, that old lovely DB2.

Even in old times, people who claims that there is a solutions that fits both cases were considered crazy. That is why no sane person considered MSSQL (leave alone MySQL) as something other that a taste-less joke.

Nowadays people forgot about designing in terms of data flows. Everything starts with installing some framework, such as Spring+Hibernate, Rails or some PHP crap. They forgot that not tables itself, but queries (which type, how often) to them is what matters, that indexes optimized for actual query flow is what performance of a server is all about, and that actual structure of tables (and corresponding indexes) must be adapted/redesigned for that particular production flow of data. That was a DBA's job.

Today some people believe that they can eliminate smart but costly engineers (DBAs or sysadmins) by some software which is marketed to them as Easy, Smart, Fast, Zero-thinking or whatever - ready meals for a mediocre crowds. OK, if you're building a 20 pages web-site for a 100 visitors per day, that might work - you can save some money and time, but, if it is a industrial or internet-scale solution, there is no chance that you can run Rails or say Code Igniter crap in production without huge changes or total redesign. No fucking way.

So, all those specialized solutions, such as memcached, redis, membase, mongoDB are about dealing with flows of technical data, such as AJAX queries from UI, logs, authorization requests, chats, photos and other unimportant things, OR about building a huge distributed cache layer above actual data store. But, of course, you cannot build a Data Warehouse out of it. (Or invent a complete different approach to dealing with data, such as map/reduce).

So, ORM is anti-pattern? It is not efficient? Ridiculous. It is just broken by design. ^_^