Time to Move On: Querying Without Nulls and Bags

Authors:

• Molham Aref
• Leonid Libkin
• Wim Martens

Reference ID: arXiv:2608.10863 (cs.DB) | Submitted: August 11, 2026

---

📜 Executive Summary

SQL stands as a monumental achievement in language design for the database community. Its primary strength lies in its declarative nature, which allows for high levels of optimizability and significantly lowers the cognitive load on the programmer.

However, the authors argue that as the complexity of modern data problems grows, we must re-evaluate the foundational decisions made during the early days of query language design.

🛠 The Problem: Legacy "Evils"

For decades, the industry has accepted certain design flaws as "unavoidable evils." The authors specifically target two:

1. Bags (Multisets): What E.F. Codd described as "corrupted relations."
2. Nulls: Often referred to as the 'billion dollar mistake'.

The authors contend that the justifications for these features are flimsy and vanish upon closer inspection.

Conceptual Comparison

🚀 The Solution: The Rel Experience

The authors draw from their practical experience developing Rel, a language designed for end-to-end relational programming. They demonstrate that it is entirely feasible to implement and deploy a system based on fully normalized relations.

The Logic of Sets vs. Bags

In mathematical terms, the transition is from bag semantics to set semantics: $\text{Bag} \implies \{a, a, b\} \quad \text{vs.} \quad \text{Set} \implies \{a, b\}$

Implementation Workflow

🎯 Paper Objectives

The authors set out to achieve the following:

• Debunk the perceived necessity of bags and nulls.
• Prove that normalized relations are viable for deployment.
• Highlight the specific advantages of a null-free, set-based language.

💻 Technical Example: Conceptual Shift

In a traditional system, handling missing data might look like this: SELECT * FROM Users WHERE Email IS NULL;

In a null-free normalized environment, the logic shifts to a relational join or a separate relation for optional attributes:

-- Conceptual Rel-style approach: 
-- Instead of a NULL column, use a separate relation 
-- linking UserID to Email only where it exists.
RELATION UserEmails { UserID, Email }

🌐 Metadata & Resources

Subjects:

• cs.DB (Databases)
• cs.PL (Programming Languages)

Links & Access:

• DOI: 10.48550/arXiv.2608.10863
• Full Text: Available via PDF on arXiv.

License:

---

This summary was derived from the arXiv submission history provided by Leonid Libkin on August 11, 2026.