News for hackers. Stuff that matters.
Re:The Curious Case of the Aggregation Query by refulgentis on Tuesday December 05, 2023 @06:34PM (#38538443)
There’s certainly merit in learning the mathematical foundations of SQL, like relational algebra.

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.

Re:The Curious Case of the Aggregation Query by derefr on Saturday December 09, 2023 @01:49PM (#38584537)
My point — that I perhaps didn't articulate directly — was that SQL is a bad "instrument" for noodling around with data in a way that actually gives you "a handle on the basics."

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.