Creating an ORM model is so simple the only time I've even given it a second thought is when composing this reply.

It's no more difficult than building tables by hand. There isn't any extra work that you wouldn't also have to do when not using an ORM.

  cursor.execute("""
    UPDATE employees
      INNER JOIN merits ON employees.performance = merits.performance 
      SET salary = salary + salary * percentage;
  """)

Please show me how much simpler and fewer lines that would be in ORM code + model definitions.

You would need to show me your DDL statements because that's the equivalent. I can generate the model from the database or the database from the model.

It's not much more effort to type "create table employees" with all the fixings as it is to type "class employees" with all the fixings.

>I can generate the model from the database or the database from the model.

Depends on the ORM. Just like "raw sql mode", not every ORM supports that. It's not an inherent feature of being an object-relational mapper, it's part of the bells and whistles of some ORM packages. And I'm going to guess you're coming from the Python/scripting universe, because generating models in other languages is definitely more complicated.

But let's pretend that all ORM software can generate model definitions from the database. Just do the update then. I want to validate your argument that a simple update in SQL is "a lot more code especially if wiring up foreign relationships." If you think an ORM is much less code, or simpler, I'd like to see how.

I think I can give a better example that isn't purely about performing updates, but is still about "simple things" and not particularly complex flows.

In my API, I have models from my ORM. These can then be used for database migrations, which allows changes in my database structure to be checked in to version control.

From there, these models are obviously used for queries within my app. Generally, you are correct that generating a simple query with the ORM is not meaningfully easier than writing the SQL myself, with the one exception being that the ORM sanitizes inputs to my queries without me having to think about it at all, which is nice.

From there though, I can use the models from my ORM to automatically validate incoming requests to the API endpoints, as well as automatically serialize the results of my queries when I want to send a response back to the client. If you're not building a REST API, obviously this might not be particularly useful, but for someone that is, it has saved me a lot of work.

Finally, generally I find code in my code is a bit easier to debug than strings.

Your example makes for good SQL but a simple ORM example:

    employee = new Employee() { Name = "Bob" }
    employee.Manager = new Employee() { Name = "Jill" }
    context.Employees.Add(employee)
    context.SaveChanges()

This would insert a new employee record for Jill, grab the primary key, then insert the record for Bob with his ManagerId field to Jill's id. If Bob wasn't a new employee, it would perform and update instead. If there were more related elements and different levels of depth the ORM would order the inserts/updates to get the necessary keys and wire everything up. After this block of code, the objects are all updated with their new primary key values. Everything is executed in a single transaction.

The ORM is performing operations on objects -- it's pretty much right there in the name -- it's going to be a poor choice for bulk updates because that's not what it's for. But again, nothing stops you from using the right tool for the right job -- whether that be an ORM or raw SQL.

  $db->employees->update({
    salary => $Q{salary} + $Q{salary} * $Q{merit}{percentage}
  });

Not that much simpler in that case, but at least lets you define the JOIN once rather than repeating it per-query.

This is by far the best ORM analogy yet.