4 ms·

I understand the usefulness of an ORM and how much its use can clean up a codebase but... truly performant queries (that take advantage of every aspect of your

I understand the usefulness of an ORM and how much its use can clean up a codebase but... truly performant queries (that take advantage of every aspect of your DB not just some vanilla lowest common denominator provided by an ORM abstraction) are done in SQL. In the end one has to make the tradeoffs between development speed (something an ORM has going for it) and performance and the eventual issue of having to handle the object impedence mismatch. For me it's just so much more clear to read a handful of queries and see how things work. You can even create user defined functions and call them like an API from your codebase (a sort of ORM) and get the best of both worlds. It's not a easy choice to ORM or not but SQL should be a skill everyone learns.

paulmd 6y ago
well, most ORMs give you the ability to drill down into native queries if you want, and often even will help you with the conversion into native objects if what you are pulling back is still a native object. So it's not a binary thing, you can use ORMs to reduce the amount of boilerplate for simple queries and then where it makes sense you can drill down into native SQL. (a lot of what ORMs give you is just a reduction in boilerplate code, manually populating 30 different fields on an object and so on.)
- gigatexal 6y ago
  in my anecdotal experience this almost never happens because devs have an aversion to putting SQL in the code.
  - paulmd 6y ago
    Most simple queries won't benefit much from hand-coded SQL and it's always there for the minority of the ones that do. And again, there is the middle ground of writing something like custom HQL that returns an object(s) of interest. Again, there is a huge amount of error-prone boilerplate that is avoided simply by doing that, the next time you add a column you don't have to chase down 27 different hand-coded functions manually populating one field at a time.

paulmd 6y ago

well, most ORMs give you the ability to drill down into native queries if you want, and often even will help you with the conversion into native objects if what you are pulling back is still a native object. So it's not a binary thing, you can use ORMs to reduce the amount of boilerplate for simple queries and then where it makes sense you can drill down into native SQL. (a lot of what ORMs give you is just a reduction in boilerplate code, manually populating 30 different fields on an object and so on.)

gigatexal 6y ago
in my anecdotal experience this almost never happens because devs have an aversion to putting SQL in the code.
- paulmd 6y ago
  Most simple queries won't benefit much from hand-coded SQL and it's always there for the minority of the ones that do. And again, there is the middle ground of writing something like custom HQL that returns an object(s) of interest. Again, there is a huge amount of error-prone boilerplate that is avoided simply by doing that, the next time you add a column you don't have to chase down 27 different hand-coded functions manually populating one field at a time.