Hacker News Reader

Comment by noisy_boy | Hacker News Reader

As someone who started their programming journey with SQL, it just feels so odd hearing about learning SQL being presented as an useful option. I get it, it just feels odd. SQL was considered table stakes in the financial IT world - if you said you didn't know SQL, people would look at you funny.

View on HN

It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything you're going to write on top. I keep ending up in situations where I'm the only SWE in the room who really knows SQL, let alone proper schema design, and I have to speak up or else they're going to build an abomination.

But for a lot of people, the focus there is in the "write on top" layer, because they enjoy it more (I suspect). Constraints etc are tested there.

But this is caused by another shift (I didn't experience this firsthand so bear with me); early databases often had multiple clients, nowadays it's often a 1:1 relationship with one application owning the DB. Which makes putting in constraints in SQL feel clunky.

The biggest casualty of that is probably stored procedures.

> The biggest casualty of that is probably stored procedures.

Not much can beat stored procs when it is dealing with multi-step heave volume stuff. But I don't miss not having to do hacks for logging and debugging compared to the flexibility offered by non-db side.

For pretty much everything else, the poor ability to log and debug makes them a headache to manage. I

You can make a decent DB with minimal constraints or stored procs, meant for regular code to use. The abominations I'm talking about are like, they use an ORM, they use meaningful fields as PKs that end up being non-unique later, or they reinvent the type system by making some tables with a json field that can mean completely different things based on some enum column.

My first job was at a financial services software company. They put everyone through multiple weeks of training on sql. That experience has been paying dividends for 25 years.

Mine was at a book publisher, so I got the books database example applied in real life lmao. The other part of that job was for a football (as in football, not handegg) magazine, they also had a database containing pretty much all football factoids from the past 100+ years. That one was used to create an annually published football almanac that was just full of match results, player stats, transfers, tables, etc.

Back in the 90s when I was in university, SQL (and databases in general) sounded like a boring topic that appealed to people who wanted to go into accounting/finance or some consultancy. I didn't study CS to learn to use an application! So, I took other practical curriculum options like operating systems, compiler writing, and graphics.

Then I went off and did distributed systems and HPC work for a decade or two, and the closest I got to "databases" was when we had to interact with LDAP. But, eventually our R&D contracts shifted and we were mixing with bioinformatics people. Then, we had a need for structured metadata management, and RDBMS seems like the right tool. So I finally had a reason to teach myself SQL, with a range of OLTP and analytics sorts of workloads on PostgreSQL.

I have found the existing ORMs in our Python landscape to be really alien and off-putting. I much prefer using the lower-level DB connector and doing my own SQL query building. We also do a bunch of generic/polymorphic work, defeating the main theses of ORMs. Mostly, our schemas are not known at development time, rather they change dynamically. There is no sense in mapping schema to classes, since a developer would have no contact with such classes. Instead, our code has to do "metaprogramming" about table definitions, keying, and reference patterns at runtime.

That was one of the needs we had during my initial days - dynamic DDLs/DMLs. It was basically a bash + SQL stack which is fairly low level. I remember discovering Perl was installed on the Sun Solaris boxes, learned it and soon everyone jumped on it and boy what a massive step-up from bash that was!

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

    > 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.

> 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

You should also learn joins and ordering/pagination. But that can be on day 2 :)

I consider those to be part of basic Table CRUD, but yes, absolutely. :)

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.

   > 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!

> 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

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.

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

I was working with a "full stack" engineer and needed to do some ad hoc data manipulation so I wrote some SQL inserts and updates. He was like "whoa, I didn't know you could do that with SQL!" I was shocked. Like, how have you been working on projects using databases this long without knowing basic SQL? I still don't think they know about DDL at all.

Still applies today in data science, one is expected to master SQL alongside Python and Excel.

Reply on news.ycombinator.com