4 ms·

That's not true. A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a fore

That's not true. A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. With SQL you will also have a lot of uncheckable strings containing code. Simple tasks are done maybe thousands of times in any one application. It's the complex tasks are rare.

daenz 7y ago
>A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. That's not a fair comparison unless you include the time and effort involved in creating your ORM models, before you can even write those 3 lines of ORM code. The effort to construct those models isn't even fully amortized over your project, since it must be maintained through schema migrations. ORMs are like putting on an exoskeleton to go buy groceries because it will let you carry your bags more easily. In my opinion, the complexity and indirection they introduce for accomplishing simple tasks do not justify their existence in the vast majority of cases.
- wvenable 7y ago
  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.
  - daenz 7y ago
    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.
    - wvenable 7y ago
      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.
      - daenz 7y ago
        >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.
        fastball 7y ago
        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.
- dillonmckay 7y ago
  This is by far the best ORM analogy yet.
yawaramin 7y ago
> With SQL you will also have a lot of uncheckable strings containing code. A good SQL access library can validate queries against the database itself at build time.
delusional 7y ago
Yeah, your "uncheckable strings" (which could be checked by spinning up a testing database) is replaced by 700k lines of code that, although tested, is still full of bugs. The Hibernate repo is 700 thousand lines of java code! There's a tendency amongst some (especially "enterprise" programmers) to forget that dependencies are also just code. If they break, you are on the hook too. You own that complexity.
- scarface74 7y ago
  So if I am using C#, I’m trusting that Microsoft wrote their other libraries correctly. Why wouldn’t I trust Entity Framework?
gernak 7y ago
I am not picturing this update taking more than 3 lines of code with SQL either. Here is an update in one of my projects with names changed: await client.query(` update table set c1 = $1, c2 = $2 where id = $3 and userId = $4 `, [c1, c2, id, userId]);

daenz 7y ago

>A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. That's not a fair comparison unless you include the time and effort involved in creating your ORM models, before you can even write those 3 lines of ORM code. The effort to construct those models isn't even fully amortized over your project, since it must be maintained through schema migrations. ORMs are like putting on an exoskeleton to go buy groceries because it will let you carry your bags more easily. In my opinion, the complexity and indirection they introduce for accomplishing simple tasks do not justify their existence in the vast majority of cases.

wvenable 7y ago
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.
- daenz 7y ago
  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.
  - wvenable 7y ago
    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.
    - daenz 7y ago
      >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.
      - fastball 7y ago
        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.
dillonmckay 7y ago
This is by far the best ORM analogy yet.

yawaramin 7y ago

> With SQL you will also have a lot of uncheckable strings containing code. A good SQL access library can validate queries against the database itself at build time.

delusional 7y ago

Yeah, your "uncheckable strings" (which could be checked by spinning up a testing database) is replaced by 700k lines of code that, although tested, is still full of bugs. The Hibernate repo is 700 thousand lines of java code! There's a tendency amongst some (especially "enterprise" programmers) to forget that dependencies are also just code. If they break, you are on the hook too. You own that complexity.

scarface74 7y ago
So if I am using C#, I’m trusting that Microsoft wrote their other libraries correctly. Why wouldn’t I trust Entity Framework?

gernak 7y ago

I am not picturing this update taking more than 3 lines of code with SQL either. Here is an update in one of my projects with names changed: await client.query(` update table set c1 = $1, c2 = $2 where id = $3 and userId = $4 `, [c1, c2, id, userId]);