I've actually seriously considered keeping all my SQL queries in their own files, and reading them into local variables on load. It would allow them to be tracked and edited individually... but I now use an ORM.
I do keep the SQL queries in their own files. The only difference is that they get loaded into the db (as stored procs) at first and then called by name. Works well.
Agreed ORM's are usually very sub-optimal. They make sense only because application developers aren't db people. And this is the problem.
I suspect for certain parts of some apps, ORM's might work OK. But in general for applications of any complexity they will break down hard and fast, and lead to bad db design, bad performance, or both.
ORM is just less work. If you write in OOP you are already creating objects anyways. Then writing get, save, and update procedures is just a lot of extra work.
The problem is then you build databases around your ORM but if you are doing a single app database, why use an RDBMS at all?
In other words, I see an ORM as an antipattern because the subset of cases where it works really well at bridging the gap you probably don't really want an RDBMS in there anyway.
And if you do make it work (encapsulating your db behind updatable views) without running into this, it's a heck of a lot more work than hand-coding SQL.....
