I believe that ORMs try to solve a problem that fundamentally cannot work. As long as you keep the usage simple and use your database as an object store, as a m

I believe that ORMs try to solve a problem that fundamentally cannot work. As long as you keep the usage simple and use your database as an object store, as a majority of projects do, all is fine and dandy. But once you start to look into your database a bit more, and try to use it for what it's capable of, you'll run into problems. It it because the fundamental building block of the data model of the languages in question here are objects, while the fundamental data block of RDBMS are relations. As soon as you try to write custom queries which join columns from other tables, then the simple table<->object mapping ceases to work, the OMR becomes lost and it starts to get in the way, and can make you lose a lot of time. I've personally settled on using a "light" ORM, which does the mapping of result sets to objects, variable replacement, and connection handling, and I write the SQL myself. It's still not ideal, because for statically types languages I need to write ad-hoc object types for query results, or deal with untyped data, but at least I don't get any surprises.