11 — Why SQL Beats Writing Relational Algebra

Relational algebra is procedural

Despite mathematical notation, it defines the steps the DBMS must perform — you are writing the query plan (1:00:41, 1:00:58).
A 1970s complaint about Codd's paper was that it was "too mathematical". The lecturer disagrees — any CS undergrad should be able to follow it (1:00:41, 1:00:58).

Two ways to express the same query (1:01:18):

Join R and S first, then apply the select filter.
Apply the select on S first (filtering on b_id), then join the smaller result against R.

Performance differs dramatically depending on the actual data (1:01:44):
- 10 tuples → irrelevant.
- Billions of tuples → you want to filter S as aggressively as possible before joining.
Relational algebra has no concept of reordering — you have specified exactly what must happen (1:01:44).
Declarative SQL lets the DBMS choose. Change the physical layout or data structures and the query does not change (1:02:12, 1:03:30).

The relational model shipped with no programming language; SQL was added by IBM a few years later (1:02:41).
Codd proposed his own language, Alpha — never implemented (1:02:41).
SQUARE, an early SQL precursor, required a keyboard that did not exist because expressions were written vertically (1:02:41, 1:03:06).
QUEL, invented by Stonebraker for Ingres (which became Postgres), was a competing language (1:03:06).
SQL became the de facto standard; a formal SQL standard exists but no system implements it exactly (1:03:06, 1:03:30).

Question: relational algebra never mentions primary keys — what if a union produces two tuples with the same key? (1:03:52)
Answer: keys are declared in the schema, and the DBMS enforces uniqueness there. At query execution time the primary key is irrelevant — joins and intersections work without knowing it. Foreign keys are the same: they are integrity constraints, not query mechanics (1:04:12, 1:04:36).