- SQL is not an artificial layer, an ORM however is
- SQL is a language, it's up to you as a developer to tune your queries against your database (e.g. create and use partitioning, indexes, statistics gathering etc.)
- If your using an ORM just to send data via a native protocol then why use the ORM in the first place?
- Performance tuning is very closely related to how you write your SQL
- This is my opinion but I think almost any usage of an ORM will mostly be bad, no real arguments to support otherwise. Let the database do the work, that's what it's there for.
- SQL alone will never help you understand if your underlying table is hashed/unordered, column/indexed or tree/ordered either.
- ORMs need not generate SQL statements. An optimized ORM can directly send the data to be inserted in a native protocol to the DB.
- The deal is that data tuning / access optimizations have no semblance with SQL or the ORM.
- Bad ORM usage / anti patterns does not mean ORMs are bad. It means people use them badly.