Well, ususally I agree 100% with what you write, and I love your way of thinking.
However, this time I really think you did not consider all the benefits of an ORM.
I am also a developer and DBA for most of 3 decades and use a plethora of ORMs and have written a considerable number of non-ORMd applications where ORMs did not exist yet, or where ORMs were unwanted by the end client.
I too think that SQL cannot be fully replaced by ORMs, and that gray matter should always be applied to see what fits better for the particular problem.
There is quite some stuff that cannot be fully or efficiently ORM-ed.
Note that I do think that ORMs can create horrific DB traffic when used without the proper experience, but that argument is valid for most technologies we use these days.
However, I want to input that ORMs bring more to the table than just abstraction.
Abstraction itself can- as you state correctly- be largely done by SQL/Views.
Having a good ORM you can do that too and:
* Have typesafety using the object model. Throughout my career I have seen many, many issues with implicit conversions, DB specific types and such.
* It vastly reduces code clutter, even compared to code using code constructs as .NET's lambda expressions to envelope the field access code with the connection/command code.
* Have automatic client-side caching (if you want), reducing DB traffic altogether. You can even deliberately pre-cache, without writing any code.
* Have automatic batching (if you want), reducing latency.
* if you are more experienced with ORMs you can use object inheritence, reducing model complexity and promoting code reuse.
* Although complex applications can give you some trouble, most of the LOB applications can be switched to another database (MySQL, Oracle) without any (or little trouble).
I do NOT think this is a big plus though. I have seen less than 10 database switches during my career, and I think choosing a specific ORM for this reason is nuts.
* AND - using a good ORM, you can actually have both. Create your views in the DB, use the ORM to create a class for the resulting recordset. You will have the mentioned benefits AND use all the speed and complexity of the DB. I do this all the time. USE THE BRAINS. This works for stored procedures aswell.
So, I think that there's more to this than just the abstraction.
There is no need to make this a ORM bash. In this case, you CAN have your cake and eat it too.
Use the DB for what it's good at. Use an ORM if it benefits your cause.
They work together you know.
DBA's will always be necessary. An ORM is just another tool in the box.