ORMs not fish, not fowl, just foul

I had to respond to Stephan Schmidt's post how "ORMs are of the past," but I'll elaborate here a bit. I've worked in multiple persistence frameworks on multiple platforms and the ORM-oriented ones are fundamentally flawed in that they refuse to leverage the strengths of relational technology. Of any patterns for data persistence I have to advocate model-view-controller rather than ORM. Programmers, including Java programmers, seem to look at relational databases as a puzzling and obtuse obstacle to programming. They install them because the customers or other stakeholders insist, or because they need data recovery, or transactions. In other words, they want everything except the relational data model. Working with Hibernate and other ORMs leave me, as a data architect, feeling trapped. ORMs cause extremely tight coupling of application code and the database schema. This coupling makes it very difficult for me to take my standard database practices - entity analysis, query optimization, or "physical-level" techniques like clustering or partitioning. The programmer might test to 200 rows of data. What happens with 500k or more rows of data is typically very, very different. Once your customer gets data into your database schema, you must treat that data as gold. And when the customer's work uncovers that the data model needs a restructure, it's a challenge for the data architect to fix it while bringing the data safely into a new schema. Then you come to the programmer and he/she/they are crestfallen that they have to change a ton and a half of code because you've screwed up their annotations, it's propagating ORM changes throughout all of the application code, and the logic stops working. Maintenance and reuse are critical to enterprise deployment and ongoing support. If you want your code to make your customer a success, you need to be able to adapt it as their needs evolve. Every time you use an ORM for data persistence, you are hardening your arteries.