Agreed. Curious what materials you've found that really drive this home?
Like 90% of googlesearch results simplify things to the point where this is missed.
[0]: https://www.sqlservercentral.com/stairways/stairway-to-t-sql...
Beginning with SQL syntax allows students to quickly create something tangible, which can be incredibly gratifying and motivating.
It’s a bit like learning to play music; while music theory is important, there's something to be said for picking up an instrument and playing a few notes to spark a passion.
The intricacies of relational algebra can be woven into the curriculum once students have a handle on the basics and can appreciate the deeper structures at play.
Implementing the sorts of things you'd use SQL to do, but using an in-memory bag-of-tuples data structure in a functional language, is a much better way to learn those basics. There's far less "grammatical magic" involved (where one extra word in the statement changes the way every step does its work); instead, each relational-algebra operation — each of what an RDBMS would call a "query-plan node" — is something you're directly describing with a line of code.
Leaning on your analogy of music:
Building an intuition for relational-algebra by using functions of Set and Tuple ADTs to transform bag-of-tuples-typed data in a programming language, is like building an intuition for music by trying to hit the keys on a piano according to a score.
Building an intuition for relational-algebra through SQL, meanwhile, is like building an intuition for music by wiring together VST modules in a DAW, to automatically generate sequences of notes, apply effects to them, level them, combine them in various ways, etc. And not even directly/interactively/visually like you'd usually use a DAW, but instead, by describing the wiring diagram using some sort of purely-textual high-level declarative VST-wiring DSL. (You only even get the visual equivalent of your VST-wiring-DSL code, if you use SQL EXPLAIN — which only works on 100%-valid SQL, so isn't great as a debugging tool for confused newbies! — and then feed the EXPLAINation into a visualizer like https://explain.dalibo.com/.)
Once you have a really solid intuition for music, you might be able to sit down and write a VST-wiring-DSL query that outputs exactly the notes you want on your first try. Just like someone who has built a really solid intuition for finite-state automata, can get a regular expression right on the first go. But neither regexps nor SQL are a good way of developing the intuition for the way the underlying formalism is "being driven" by the abstract program.
If you want to understand regexps well, you should first do what the regexp would be doing for you. Write your own string parser, as a finite-state automata module, consuming characters (and potentially keeping a lookbehind buffer), and outputting matches and captures.
If you want to understand SQL well, you should first do what the SQL query planner would be doing for you. Implement your own query plan, using a chain of function calls to something like Clojure's lazy-sequence functions, or to Elixir's Enum and Stream modules.
I run the tech side of a company almost entirely built on complex SQL queries. If I were to take a fresh college student and "teach them SQL"... well, I wouldn't teach them SQL. I'd teach them relational algebra: projection, selection, join, etc. as mathematical operators over bags of tuples. I'd make sure that they could show me what the bag-of-tuples looks like at each step, as each operator is applied.
And then, once they have that solid understanding, I'd show them, in order:
1. that there exist these systems called RDBMSes that maintain durable, mutable bags-of-tuples they call tables (which is weird when you think about it; coming from a math world, a relation should be an immutable mathematical object);
2. that these systems accept a COBOL-like declarative syntax for either referencing their tables (TABLE foo) or expressing relational algebra upon their tables (SELECT ... FROM foo ...);
3. that these systems also accept COBOL-like imperative syntax for modifying the bag-of-tuples contained by a given table (INSERT, UPDATE, DELETE);
4. and that, completely unnecessarily, these systems also have a COBOL-like imperative syntax for modifying the definitions of the tables themselves (unnecessary because the data-definition schema could have just been, themselves, tables that you modify through DML statements. INFORMATION_SCHEMA exists, but it's read-only in every RDBMS I've ever seen.)