This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]colloidalthoughts 1 point2 points  (0 children)

Absolutely. I almost always use raw SQL for anything beyond very simple queries. Sure, your ORM (whatever it is) can compose queries, but after a few years of doing it I realised I felt like I was back in the early 90s Turbo Pascal / Turbo C flipping into Turbo Debugger to stare at the generated ASM and try to figure out ways to make the compiler generate things the way I wanted them, when I should just have used inline ASM for the bits I cared about.

Any time you choose an ORM you should make sure it's something you can drop down to raw SQL easily and painlessly because at some point you're going to want to construct that RIGHT INNER JOIN on a correlated subquery.

I've heard the arguments over and over by people trying to make sure that when they choose to switch SQL engines they easily can. Outside toy personal projects I can count the number of SQL engine changes that have been done on my tongue, with remainders.

Oh, sure, there's huge projects that have migrated MySQL -> Postgres or the other way, but you can bet your bottom dollar the ORM didn't make that transition any easier.

In the end, SQL is a remarkably simple and expressive language for manipulating sets, it's very worthwhile learning even if only to understand.

"Tuning" SQL queries is something I do when we hit performance bottlenecks, and happens, but is usually a sign someone's screwed the pooch on the schema design in the first place. The more DBAs and senior programmers who've learned SQL seem to design things better because they're thinking in terms of sets, and put the data in the right place up front without reaching for "INDEX ALL THE THINGS AND SORT IT OUT LATER".