Time to Move On: Why SQL's Nulls and Bags Are a 'Billion Dollar Mistake' We Can Avoid
Time to Move On: Querying Without Nulls and Bags
SQL's success stems from its declarative nature, but its foundational choices—nulls and bags—are often tolerated as unavoidable evils. Drawing on their experience building Rel, a language for end-to-end relational programming, the authors argue these features are not only avoidable but harmful. They debunk common justifications for nulls and bags and highlight the benefits of a null-free language with set semantics, offering a path toward fully normalized relations that Codd would approve of.
We argue that the evil is completely avoidable: reasons offered for justifying bags and nulls evaporate at a closer examination.
- mamcx
It has good points, but has 2 major problems, IMHO, that we observed when I was part of a team building a RDBMS:
* It again ignore the best solution for nulls: Algebraic types. Once you have this much get solved for free
* The argument against bags:
The best idea of the paper is that a RDBMS in fact internally do different data structure and temporal representations that are not of concern to the user. Correct.
THEN it jumps to the conclusion that bags should not be presented to the user, despite the fact acknowledge it need to display them.
This is wrong, and the major reason that is always overlooked is that assume that 2 identical values are wrong to exist.
I can have "Jhon, Jhon", be 2 separate persons, not know at this time more to disambiguating, adding a Id do nothing to help me, and yet, this data is correct as is.
The language MUST allow me to deal with this. It will absurd to claim an array language, procedural, functional, imperative, declarative, etc can and a relational can't.
It say the lang is intentionally limited for purity, that true, is ideal in some cases, but that purity is what the engine/compiler should track, but not distort MY DATA for this.
And the part where the perf of having bags dismissed is easy to debunk: implement a dbms and profile.
P.D: Is true that set unlocks lots of benefits, and in some cases are ideal. But very fast once you hit the real world you see that need both, similar how btrees alone is not enough, and then there is hash-based i […]
- bbkane
It's unfair, but my first thought after reading the abstract was "oh great, another one".
There have been several languages claiming to fix SQL and none of them (to my knowledge, I'd love counter examples) have achieved widespread enough adoption to be named a proper successor.
Reasons I can guess:
- SQL's 50 years of entrenchment- all RDBMSs speak it! Most monitoring systems speak it! Any successor language needs a good interop story so people can use it with their existing systems.
- SQL is good enough for run of the mill day to day tasks- and these days by the time I'm lost in recursive queries or window functions, I can ask an LLM for help. Maybe a successor language can win on IDE support or other parts of the dev/agent experience
Successor languages also tend to only replace parts of SQL (usually the queries, not the insert/update stuff). I think PRQL does this (once again I'd love to be wrong). Now the dev has to learn two languages?
I guess my point is that a successor language, can't just fix the semantic issues with SQL, to be successful it also has to provide large ecosystem (and maybe political) steps up. I didn't see any of that in this abstract, which kills my excitement.
- reaanb2
Can we also move on from speaking about rows as if they're vertices in the conceptual model graph, and start treating them as n-ary associations / facts?