Very good

Very good article and these are the reasons me and my team are not using ORMs very often, but DBALs instead. Although I think this goes more in the sphere of Database Access Layer where the developer can executes custom queries and fetches arrays for a result. One of the main goal of ORMs is to use more objects and less queries and not to take care about query control, witch is not a very good practice to me. Thank you!

Yes, as mentioned in the article, ORMs are not very suited to take the most of the underlying database.

For applications that squeezing all bits of performance is important, maybe you should not use ORMs, at least those that return everything as objects.

I use a ORM tool for generating ORM code. The generated code uses Metabase DBAL that I have been developing since many years ago.

phpclasses.org/package/20-PHP-PHP-D ...

The ORM tool is called MetaStorage. I can define what classes it generates and which functions the classes need, so it does not generate fat models.

Another thing is that it can also generate report classes, which are precisely for executing queries that retrieve results in arrays, not objects, for read-only purposes, like display or even sending newsletters. It would take much memory to treat everything as an object.

meta-language.net/metastorage.html