3 ms·
If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.
by daenz 7y ago
If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.
- peterhadlaw 7y agoJust because a job is simple doesn't mean it doesn't take time & effort. A tool can be helpful if it reduces the time or effort to accomplish something.
- Rapzid 7y ago> Just because a job is simple doesn't mean it doesn't take time & effort See digging.
- wvenable 7y agoThat'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 agoCreating 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 agocursor.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 agoYou 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 agoI 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.
- 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 agoYeah, 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 agoSo if I am using C#, I’m trusting that Microsoft wrote their other libraries correctly. Why wouldn’t I trust Entity Framework?
- gernak 7y agoI 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]);
- kodt 7y agoIt might not save a lot of mental "effort" but they still save a lot of time that would otherwise be spent on writing simple boilerplate code.
- _frkl 7y agoI don't think that is what parent wanted to say. It's still a lot of boilerplate code and config that can be avoided by using an ORM for the 'simple' parts of an application. And if you use a framework like sqlalchemy, you still have access to the lower levels if it turns out the ORM abstraction is unsuitable.