161–170 of 243 posts
Earlier quoted context omitted.
> Not a tutorial. Not an ORM. Actual SQL ah, this is an Ai article
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.
She stopped using that name.
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.
Earlier quoted context omitted.
The code is simple to maintain until the database changes. Then you will experience the pain of SQL
I’ve experienced what you’ve mentioned before, ORM or not you have issues if you’re shuffling the schema around. Cool.
> If you are a junior developer, “learn SQL properly” is the most valuable 40 hours you can spend. Not a tutorial. Not an ORM. Actual SQL: joins, subqueries, window functions, query plans. That investment pays you back at every job, in every stack, for decades This is the power of low-level reasoning. Today, even for a junior developers, even if they have AI that solves syntax problems, SQL teaches you to reason and…
The breakthrough for me was thinking in terms of sets and not in terms of "how would I do this imperatively." 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.
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.
It is a critique of modern SQL and a suggestion for "SaneQL":
"SaneQL features a straightforward and consistent syntax, which improves its learnability and ease of implementation. Additionally, it provides extensibility, with the added ability to define new operators that integrate seamlessly with the existing built-in ones. Unlike most data frame APIs and NoSQL query languages, SaneQL fully embraces the core principles behind SQL, especially multiset semantics."
https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf
A colleague of mine is working on an implementation of these ideas:
Earlier quoted context omitted.
> Not a tutorial. Not an ORM. Actual SQL ah, this is an Ai article
So AI also thinks people somehow get away only with ORM without understanding SQL? 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.
Earlier quoted context omitted.
“Fundamental” rather than “low-level”. Which also matches the article picture.
I was reacting to the parent post. And F and LL are very different. I'd say F is a more subjective metric.
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…
Learn SQL (because it's basically the only option) but much more importantly, learn databases. Know why atomicity, consistency, idempotency, and durability matter. Understand the wire protocol and the client-server model. Do relational data modeling; think beyond databases as a dumb store. Join. Know when to normalize. Internalize indexing strategies. Think deeply about what work belongs on the database server (work…
I agree with everything except this: > Understand the wire protocol and the client-server model. I'm a DBRE, and have locally compiled MySQL with debug symbols to step through something with gdb. I have yet to examine the wire protocol for MySQL or Postgres beyond a brief read from docs. I'm not saying it's not useful in some circumstances, but I can't think of a reason why a developer would ever need to know it.
Here's an "understand the wire protocol" story:
Years ago I dealt with a Customer's thick-client Win32 ERP application that back-ended into Oracle. They wanted to use it across a VPN. They naively thought bandwidth would be the major potential showstoppper and did measurement of bandwidth usage on their own. The app didn't throw around many bits so the Customer declared the test a success and spent the money on the VPN solution.
After the VPN was implemented they were unhappy w/ the performance of the app and asked me to take a look.
The application was built with individual SQL queries "bound" to many of the UI controls. Depending on what the user was doing, displaying a dialog might require 20+ round-trips to the Oracle server. The developers just assumed LAN latency and gave no thought to minimizing round trips.
Web devs are used to dealing with RTT latency today, but this was another time. The devs had no sense of how the wire protocol worked and ended-up making users like my Customer hamstrung into "solutions" like Remote Desktop / VDI.