If you see SQL where someone wrote a SELECT and is then using a cursor to loop through those results and do other queries, you've found the person who is still thinking imperatively.
Prolog teaches logical constraint based thinking.
ML/Lisp/etc teach functional thinking.
There is a lot of use in learning these other things beyond the standard imperative thinking from C/Python/Java/etc. Since some problems reduce their complexity significantly in one form or another.
To a first approximation, yes. But 'client-side joins' can be a valuable tool when the database engine won't cooperate. For some queries and some engines, you can do a select with a join to get everything you need in one query, but a select to get a list of ids followed by a union of selects (not an IN query) to get details for each id will have the results at the client sooner, with less load on the database, at some potential loss of consistency. Your client needs to be within a reasonable round trip of the server or the two queries approach won't get the answer faster.
Same with UNION vs IN. If you union 10 queries for one row each by id, it'll hit the index every time; but if you do it with IN, maybe it decides to do an index scan which takes longer.
You could say well the database engine is broken if client-side join works better than database-side join, and sure it probably is, but given the choice of fix the database engine or do a client-side join, I know which one is feasible in the short term.
Worst case, you could CREATE MATERIALIZED VIEW whatever would've happened in that temp table.
At the end of the day, your single query will be faster.
Every major database uses nested loop, hash, or sort-merge joins. If the data is small enough to fetch in a second query, I don't see any scenario where it would make a query spill to disk when it otherwise wouldn't have (except those pesky OR's).
Most JOIN issues can be resolved by composing using sub-queries/CTE's to defer a join to a smaller intermediary result, and the only time this generally can't be done is if you need a predicate on the joined table.
> you've asked the database engine to sort things
I've only found this to be true when there's an OR condition where the single query ends up doing a bitmap against every row, in which case a UNION will be faster since it's just appending two already-index-ordered streams.
> Same with UNION vs IN
A union is almost always going to be worse - most query planners cannot optimize across queries in a UNION, so each query is going to have separate ops vs. a single op with the IN. The only case I've seen this be true is for multi-column predicates with an OR clause against a composite index. I just tested the former in both Postgres and MSSQL and the UNION query cost was 2x the IN clause.
> maybe it decides to do an index scan which takes longer
This has not been my experience unless the table statistics are bad.
The quote that comes to mind: "His pattern indicates two-dimensional thinking."
> I've done far worse than kill you. I've hurt you. And I wish to go on hurting you.
Which I believe is a paraphrase of the Oracle Master Agreement.
I'd say SQL is a very high level language.
"SQL teaches you to reason and approach problems logically" -- I kind of agree here. It teaches relational data mgmt. I think it is better to attack most software design challenges at a higher level, and --once settled at that level-- consider how to "serialize" those solutions to an RDBMS (if that's the tech that you've chosen for persistence; still a very solid choice after 50+ years!).
In my experience, SQL sorely misses sum-types. So I need to find a way to serialize the sum-types of my domain model to SQL.
SQL is still very useful after all these years: that's the point that anyone will agree on.
Not low level. Not "fundamental" (by most definitions I can think of).
I understand the point you're trying to make, and yes, it does seem like SQL is "low-level" from the perspective a wrapper like ORMs or a GUI db browser tool with menus for filtering data.
But it's also worth remembering that SQL itself is a high-level wrapper that hides the lower-level C/C++ code of the db engine that has the loops that iterate through b-trees, 8k data pages, memory blocks of the buffer cache, etc.
And C/C++ itself is a high-level wrapper that hides the logic in lower-level Linux o/s system calls that manages RAM and disk i/o.
And Linux itself is a high-level wrapper that hides low-level device drivers like SATA/SSD memory-mapped IO ... and so on and so on.
Depending on the type of app, you can ignore all the lower levels and just work at the abstraction level of higher-level wrappers.
ah, this is an Ai article
She stopped using that name.
Funny thing is, that is always argument of „anti ORM” people.
I yet have to see someone actually argue that you don’t need to understand SQL and ORM will suffice in the wild. Then also find devs who can’t do a simple join as joins and index usage is not some black magic and is still required to use ORM properly.
Well that's because decades of bitter experience has told us all that object graphs rarely map cleanly to sets of relationships.
However, I do think that must have been the original idea as tools such as Hibernate tried so hard to obscure the underlying SQL and database. As a result all Hibernate objects have their own particular identity requirements which only made sense to a developer that knows what's going on under the hood.
Like an early article having headline "ORM will replace SQL knowledge".
I am professional dev for 15 years and hobbyist for 20 years and I might have missed something. But only thing I do remember was "anti ORM" people nagging how "one should really know SQL" - where I never heard anyone saying "don't learn SQL" maybe only NoSQL hype... but no one else.
Yes, LLMs overuse that pattern. But it's a valid rhetorical device used for many , many years by human authors. Quite often too, especially in philosophical writing, and fantasy novels.
I'll give you that it wasn't often used in blogs or tech articles, but LLMs have been around long enough to have influenced human writing in other domains without the entirety of the content itself being LLM generated.
But its called out so often I swear people online will go read some classics and accuse them of being AI generated.
I'm by no means a senior dev, but I don't know if I fit in the box of a junior either.
Regardless, SQL is proving enjoyable. But I really like logic, so it fits.