> The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational)
(This is to OP rather than you)
Well if that's the argument he's making, one example I can think of, in the case of an extremely complex update, while it always can be done in pure SQL, it is much easier to logically code using an ORM, perhaps even using individuals rather than sets (the horror). And while this implementation might execute slower (.1 second vs .01 second), it is vastly simpler to read and refactor without screwing something up (ie: economically cheaper), and as for the performance argument, it only needs to be fast enough.
The problem is, in the real world the performance divide between iterative and set-based solutions often spans much more than just one order of magnitude. For someone who's got solid experience in constructing set-based queries, the SQL solution can quite often be simpler to read and refactor as well. That's admittedly a big 'for', though. Good database folks reason about this stuff in fundamentally different ways, and there's a lot more to creating a good database person than simply teaching a programmer SQL.
In respects like that, ORM's greatest benefit is also its greatest downfall. Using an ORM means you can put people who don't have a strong grasp of databases in charge of your databases. Sadly, it also means that you've put people who don't have a strong grasp of databases in charge of your databases.
For that matter, only needing to be "fast enough" is fine if you're the only kid in the playground. That's often a safe assumption to make if you're writing app code, but less so with databases. If the database is being shared by a number of applications, or if the server is hosting multiple databases, or if you have to worry about concurrency, then being "fast enough" probably isn't enough. Because you've also got to think about all the other ways that your queries could be affecting everyone else, and making sure you aren't subjecting your server to the tragedy of the commons.
Which comes to another nice thing about having a dedicated database person. It means there's someone whose official bailiwick is the DBMS. If app A isn't experiencing any performance problems itself, but is causing performance problems for app B (say, because of some perverse locking situation), that's a bug that a DB guy is best positioned to diagnose and fix. If the application isn't too tightly coupled to the database (i.e., sprocs are in place) then he can even quietly fix it on the server side without having to hassle anyone about the application code. A team that's too ORM-reliant, on the other hand, risks failing to include anybody who's even well-equipped to recognize the problem, let alone fix it.
(This is to OP rather than you)
Well if that's the argument he's making, one example I can think of, in the case of an extremely complex update, while it always can be done in pure SQL, it is much easier to logically code using an ORM, perhaps even using individuals rather than sets (the horror). And while this implementation might execute slower (.1 second vs .01 second), it is vastly simpler to read and refactor without screwing something up (ie: economically cheaper), and as for the performance argument, it only needs to be fast enough.