flâneur — a map of the web's best reading

Against SQL

scattered-thoughts.net · 7,171 words · saved by 2 readers

This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write. The fact that these issues exist in our dominant model for accessing data has dramatic downstream effects for the entire industry: The core message that I want people to take away is that there is potentially a huge amount of value to be unlocked by replacing SQL, and more generally in rethinking where and how we draw the lines between databases, query languages and programming languages. Talking about expressiveness is usually difficult, since it's a very subjective measure. But SQL is a particularly inexpressive language. Many simple types and computations can't be expressed at all. Others require far more typing than they need to. And often the structure is fragile - small changes to the computation can require large changes to the code. Let's start with the easiest examples - things that can't be expressed in SQL at all. For example, SQL:2016 added support for json values. In

TLDR The relational model is great: A shared universal data model allows cooperation between programs written in many different languages, running on different machines and with different lifespans. Normalization allows updating data without worrying about forgetting to update derived data. Physical data independence allows changing data-structures and query plans without having to change all of your queries. Declarative constraints clearly communicate application invariants and are automatically enforced. Unlike imperative languages, relational query languages don't have false data dependenci

Explore this link on the map →

saved by

related reading