> If we'll be talking about strawmen, the idea every SQL query is composed of many concatenated string pieces is the biggest of them all. I'm usually careful a

> If we'll be talking about strawmen, the idea every SQL query is composed of many concatenated string pieces is the biggest of them all. I'm usually careful about using such words as "never" and "always". However, I have yet to encounter a non-trivial application built on top of raw SQL where this doesn't come and bite you. Of course you can't statically check your ORM-built query, but just like with static typing, you can still avoid many problems this way. > Regarding stray commas... please: listOfIdents.join(','). It's not rocket science. Plus, I'm not necessarily advocating you use string functions to build queries, there are many small helpers to be had when you need to build a complex query, but the point is to know when to stop, and not try to completely hide the resulting SQL from the user of such libraries. That's just one example. I've done complex dynamic queries with joins and aliases, and frankly, that's ugly with an ORM. Without it, it's an abomination. And I'll point that most (all?) ORMs let you use raw SQL. > If you can't control when and how your database gets called, if you can't control select locking, and transaction isolation levels, if the vast majority of its functions and syntax is out of reach, you can only do the most basic of CRUD operations on SQL. I'm not the biggest ORM advocate there is, but even I have to admit that persisting a complex object graph using an ORM is way easier than without it. The problems arise (usually) when you combine ORMs with naive developers attempting to get a lot of data out of the database. I think you dismiss too easily the advantages you get from a good ORM (not that there are many of them), but I agree they're full of performance pitfalls as well (lazy collections being the most prominent one).