181–190 of 243 posts
That's true. SQL knowledge is one of the few skills that didn't age. 1. C language. 2. *nix tools (shell and friends). 3. SQL. 4. Basic IPv4 networking. These things I learned around 20 years ago, they didn't change much and they are useful for me to this day.
Well, IPv4 is obsolete.
Earlier quoted context omitted.
> Not a tutorial. Not an ORM. Actual SQL ah, this is an Ai article
Can we stop calling specific literary devices as automatically AI? 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…
Strong agreement. Also applies to regular expressions.
Eh... yes but, I can write a sql query and come back a year later and understand it at first glance, or maybe if its really complicated a minute or two. Writing a regex involves always looking up the syntax, and being unable to read it an hour later without having to carefully disect it. I say this with 20+ YOE and I think I am better than the average bear with them. That said, knowing what they can do is important a…
No. I mean, I believe it does for you. I use it often enough that it's always fresh. On the other hand, I always need to look up the syntax of CREATE TABLE. My experience can be described the same as yours.
Earlier quoted context omitted.
I'm not sure I follow. Fetching the data in one query should almost always be faster and more efficient - the same work is being done regardless, except now you have the additional overhead involved with a second query (network and connection overhead, parsing etc.)
Depends on how the database engine sets up the join. I've seen queries where the join ends up spilling into a temp table and it takes a lot longer to do it that way. IIRC, this can happen especially if you've asked the database engine to sort things. 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 whi…
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.
Wow, JavaScript ecosystem is bad!
> Now try this experiment with [scrubbed] JavaScript [scrubbed].
Wow, JavaScript is great!
Earlier quoted context omitted.
Darn. I write exactly like this. You need to consider that people write in different ways, and the LLM is choosing from among the different styles.
I heard it mostly writes in a style associated with low-class people from Kenya.
Earlier quoted context omitted.
I'm not sure I follow. Fetching the data in one query should almost always be faster and more efficient - the same work is being done regardless, except now you have the additional overhead involved with a second query (network and connection overhead, parsing etc.)
Depends on how the database engine sets up the join. I've seen queries where the join ends up spilling into a temp table and it takes a lot longer to do it that way. IIRC, this can happen especially if you've asked the database engine to sort things. 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 whi…
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.
Earlier quoted context omitted.
> Not a tutorial. Not an ORM. Actual SQL ah, this is an Ai article
Can we stop calling specific literary devices as automatically AI? 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…
I’d say the most impactful thing is not to learn SQL, but set theory. Well-written SQL is about thinking in sets. I cannot tell you how many poorly written procedural stored procedures I’ve replaced with a single performant SQL query over the years. This is because the most impressive part of the SQL ecosystem is the DBMS engine’s query plan. Though, yes, you have to know how to influence it. I find ORMs also tend to…
I think I had a pretty good understanding of set theory through programming, and although I tried to get into the more mathematical side of it, I found most things to be 1. trivial (because I was used to thinking in lists, sets, hashmaps, etc.), or 2. irrelevant to me. The latter was a shame, because I've always liked the abstraction of math, but I couldn't help but feel I wasn't learning anything actionable when lea…
Those kinds of patterns would often replace manual loops in stored procedures and opened up set theory-focused way of thinking. These patterns are made more performant and easier with good relational modeling, of course.