So wrong, you always want to know how your database works, you should be tuning ...

vkaku · on Sept 4, 2019

- SQL is like putting an artificial layer to insert the values you want to insert with some ('') around it.

- 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.

JacKTrocinskI · on Sept 4, 2019

  - 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.