SEQUEL: A Structured English Query Language (1974)
dl.acm.org
dl.acm.org
"SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company."
Thanks for the link. I actually do like the syntax of SQUARE a little, and I'll definitely look into the predicate logic-based query languages like DSL ALPHA that came before that!
If anyone is interested in the Codd paper on predicate logic-based language: https://dl.acm.org/doi/pdf/10.1145/1734714.1734718
And more on SQUARE: https://dl.acm.org/doi/pdf/10.1145/361219.361221
Edit: This is a treasure trove of literature that's gone me by. I'm very grateful for OP bringing it to my attention. Relational data and SQL are things that are basically part of my fabric of existence and I've never questioned them or investigated why they were invented in the first place. It's definitely enlightening to do so. Here's the background to why relational data in the first place: https://dl.acm.org/doi/pdf/10.1145/362384.362685
Second edit: I love the parallels you can draw to how one might query in-memory data in a general purpose language, ranging from iterative loops (low-level) through list comprehensions (predicate logic) into functional looping pipelines like LINQ or Java Streams (calculus-based).
"The original name SEQUEL, which is widely regarded as a pun on QUEL, the query language of Ingres,[14] was later changed to SQL (dropping the vowels) because "SEQUEL" was a trademark of the UK-based Hawker Siddeley Dynamics Engineering Limited company.[15] The label SQL later became the acronym for Structured Query Language."
https://en.wikipedia.org/wiki/SQL
Indeed, reading through the paper, I think it's too similar to modern SQL to be considered a different language.
Also, anecdotally it seems like the "sequel" preference is relegated to the old-timer Oracle and SQL Server crowd, whereas the newer Postgres/MySQL/SQLite crowd prefer to call it "ess que ell" (simply because it's the obvious way to say it).
It’s like .JPG files: sure, you can call them ‘Jay Pee Gee’ files, but it’s easier to call them ‘Jay-Pegs’.
It always looked to me as if somebody back then in the database wars tried to word play on each other, one way or another.
Interestingly his daughter from the third marriage is the founder of Anapurna films, and produced Her - the movie which is basically the ad for GPTo, but like 10 years earlier.
It's amazing how much work an average developer could save himself if they knew just a bit more than basic SQL constructs and the average operator if they knew a bit more than basic configuration options.
I'm not asking to read the whole manual. (If your RDBMS is SQL Server or Oracle, that'd take a while...) Just the table of contents, so you know what you don't know.
I'm still in the habit of reading books when I pick up a new technology. It isn't necessary to get things done - I've never read a book on python but can still get things done in it - but making the book bedtime reading has been really effective. I don't try to memorize or apply everything, or even do the exercises. I just read it, and even if I don't remember the details, I'll know the features are there. How else will you learn what you don't know that you don't know?
Especially around UPDATE [0] and MERGE [1].
A lot of "data engineering" complexity and data pipelines are necessary because of the lack of more-than-superficial knowledge of SQL.
Inexperienced developers talk about DAGs of execution and whatnot, without ever realizing they describe atomic (ACID) operations an RDBMS can do out of the box.