4 ms·

It's very strange too. You can learn something like ~90% of useful SQL in an afternoon. The remainder is stuff that you only really need for extremely performan

It's very strange too. You can learn something like ~90% of useful SQL in an afternoon. The remainder is stuff that you only really need for extremely performance sensitive operations

noisy_boy 4mo ago
That is exactly what I was thinking. There is such a low barrier to entry with an outsized payoff.
crispyambulance 4mo ago
> You can learn something like ~90% of useful SQL in an afternoon. Oh, HELL NO! It's an ugly little language that one has to come back to and re-learn over and over at different levels of sophistication. Nothing wrong with that, but to suggest it's trivial is a gross mischaracterization.
- bluefirebrand 4mo ago
  > different levels of sophistication Most of those are not necessary for 90% of use cases I'm not taking the piss either All most people really need to know is table CRUD, row CRUD, and a bit about indices. For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases
  - therealdrag0 4mo ago
    You should also learn joins and ordering/pagination. But that can be on day 2 :)
    - MayeulC 4mo ago
      [dead]
    - bluefirebrand 4mo ago
      I consider those to be part of basic Table CRUD, but yes, absolutely. :)
- sgarland 4mo ago
  I’m a DBRE, and also happen to like SQL. With that as a disclaimer, I really do not think it’s a difficult language to learn. Learning the intricacies of your RDBMS’ behavior for various functions (like MySQL’s ORDER BY and GROUP BY optimizations) is complicated, but that’s what docs are for.
  - crispyambulance 4mo ago
    > I really do not think it’s a difficult language to learn. Neither do I, but there's huge distances between "spend-an-afternoon-intro-on-it" and "learn-it-well-enough-for-occasional-work" and "learn-it-enough-to-build-serious-databases". Of course, everyone in HN is "advanced" so what do I know!
    - bluefirebrand 4mo ago
      > learn-it-enough-to-build-serious-databases This is more about infrastructure than SQL though. You don't need to know any fancy SQL to do streaming replication or whatever, for instance. You're correct that being good at Managing Data is a complex domain with a lot of gnarly bits, but I was talking about Writing SQL being fairly easy
ako 4mo ago
I think the hard part is not the syntax itself but the shift in thinking: instead of procedural state manipulation expressing the desired end result in declarative set based relation algebra. I see developers struggling with breaking down complex queries in (inline) views / CTEs, thinking they need parameters, when things can be expressed as a queries on another query. Complaining about the lack of reusability, but not knowing about views.

It's very strange too. You can learn something like ~90% of useful SQL in an afternoon. The remainder is stuff that you only really need for extremely performance sensitive operations

noisy_boy 4mo ago

That is exactly what I was thinking. There is such a low barrier to entry with an outsized payoff.

crispyambulance 4mo ago

> You can learn something like ~90% of useful SQL in an afternoon. Oh, HELL NO! It's an ugly little language that one has to come back to and re-learn over and over at different levels of sophistication. Nothing wrong with that, but to suggest it's trivial is a gross mischaracterization.

bluefirebrand 4mo ago
> different levels of sophistication Most of those are not necessary for 90% of use cases I'm not taking the piss either All most people really need to know is table CRUD, row CRUD, and a bit about indices. For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases
- therealdrag0 4mo ago
  You should also learn joins and ordering/pagination. But that can be on day 2 :)
  - MayeulC 4mo ago
    [dead]
  - bluefirebrand 4mo ago
    I consider those to be part of basic Table CRUD, but yes, absolutely. :)
sgarland 4mo ago
I’m a DBRE, and also happen to like SQL. With that as a disclaimer, I really do not think it’s a difficult language to learn. Learning the intricacies of your RDBMS’ behavior for various functions (like MySQL’s ORDER BY and GROUP BY optimizations) is complicated, but that’s what docs are for.
- crispyambulance 4mo ago
  > I really do not think it’s a difficult language to learn. Neither do I, but there's huge distances between "spend-an-afternoon-intro-on-it" and "learn-it-well-enough-for-occasional-work" and "learn-it-enough-to-build-serious-databases". Of course, everyone in HN is "advanced" so what do I know!
  - bluefirebrand 4mo ago
    > learn-it-enough-to-build-serious-databases This is more about infrastructure than SQL though. You don't need to know any fancy SQL to do streaming replication or whatever, for instance. You're correct that being good at Managing Data is a complex domain with a lot of gnarly bits, but I was talking about Writing SQL being fairly easy

ako 4mo ago

I think the hard part is not the syntax itself but the shift in thinking: instead of procedural state manipulation expressing the desired end result in declarative set based relation algebra. I see developers struggling with breaking down complex queries in (inline) views / CTEs, thinking they need parameters, when things can be expressed as a queries on another query. Complaining about the lack of reusability, but not knowing about views.