As much as I love relational databases, I have not actually ever ventured outside of SQL for describing queries. Its dominance is near-total. I've never even thought that there might exist something else. But of course, SQL didn't exist since time immemorial, and there must have been things before that.
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!
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).
That solves it then. When I was a fresh cheeked starter at IBM, the grey beards always called it "sequel", whilst we called it "ess queue ell". Always listen to the grey beards
No, I am adamant that "sequel" is worse than "ess que ell". Most people who learned SQL on their own already call it "ess que ell" (a lot of my colleagues at work), because they never had a greybeard over their shoulder saying it be called "sequel". There's zero benefit in insisting it be called "sequel" other than to introduce an additional bump for people learning it all over the world. Reject sequel, join SQL.
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).
Never touched Oracle or SQL server. Worked in startups with MySQL or Postgres and BigQuery/Snowflake/Redshift. It has always been “sequel” in all the startups I’ve worked at. I think it just one of those things.
That format is actually properly called JPEG (Joint Photographic Experts Group), and the extension '.jpeg' is commonly used on *nix OSes. Using '.jpg' only became the standard on DOS/Windows in conformance with the old 8.3 filename constraint -- the same reason HTML files are often '.htm' rather than '.html' on Windows.
"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."
Is this the same thing Larry Ellison (Oracle CEO for life) took (stole?) from IBM back in the day…?
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.
Some of the example data here is surprisingly similar to the Oracle default tables. The EMP table in particular seems to just be an extended version of the original.
Public service announcement: if you haven't read the table of contents of your RDBMS of choice, please do it now. Bonus points for reading a couple of chapters.
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.
In my first software job I didn't have enough to do all day, my defined responsibilities were less than 15 hours a week. I found other useful stuff to do, but there was still a ton of downtime. This was in 1999, I had no phone to scroll. I read "Inside SQL Server" cover to cover (400 pages). This was a huge lift to me, I understood so much more about writing efficient queries and tuning - I was nearly fresh out of college and better at SQL than anyone else in my department. I'm still benefiting from this today, even though I haven't used SQL Server itself since 2008. New knowledge latches onto existing knowledge, and the gains accumulate your whole career.
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?
Similar here... also, when you need to reference something from a book, I find it easier to recall roughly how far into a book it was physically. Vs trying to search for something in digital media. I am not using mostly digital as having a lot of physical books is a pain at times, and easier to read an ereader in bed.
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.
While I can't stand Oracle as a company, I have very fond memories of Oracle RDBMS documentation around the early 2000s. And the product itself was also leagues ahead of the competition. I feel guilty even today thinking about the SQL abominations I've thrown at it under the guidance of a very ambitious product/project manager that seemingly didn't understand the difference between a OLAP and an OLTP instance. And most of the time, the optimizer and query engine and whatever governed the allocation of resources in Oracle found a way to satisfy my SQL monsters without bringing everyone else down to a halt.
"SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company."