The Case Against SQL
'Long-time Slashdot reader RoccamOccam shares "an interesting take on SQL and its issues from Jamie Brandon (who describes himself as an independent researcher who's built database engines, query planners, compilers, developer tools and interfaces). It's title? "Against SQL." The relational model is great... But SQL is the only widely-used implementation of the relational model, and it is: Inexpressive, Incompressible, Non-porous. 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: - Complexity is a massive drag on quality and innovation in runtime and tooling - The need for an application layer with hand-written coordination between database and client renders useless most of the best features of relational databases 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... I'd like to finish with this quote from Michael Stonebraker, one of the most prominent figures in the history of relational databases: "My biggest complaint about System R is that the team never stopped to clean up SQL... All the annoying features of the language have endured to this day. SQL will be the COBOL of 2020..." It's been interesting to follow the discussion on Twitter, where the post's author tweeted screenshots of actual SQL code to illustrate various shortcomings. But he also notes that "The SQL spec (part 2 = 1732) pages is more than twice the length of the Javascript 2021 spec (879 pages), almost matches the C++ 2020 spec (1853) pages and contains 411 occurrences of 'implementation-defined', occurrences which include type inference and error propagation." His Twitter feed also includes a supportive retweet from Rust creator Graydon Hoare, and from a Tetrane developer who says "The Rust of SQL remains to be invented. I would like to see it come."' -- source: https://developers.slashdot.org/story/21/07/18/1844225 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 577-5304 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/
On Mon, 19 Jul 2021 at 12:19, Peter Reutemann <fracpete(a)waikato.ac.nz> wrote:
His Twitter feed also includes a supportive retweet from Rust creator Graydon Hoare, and from a Tetrane developer who says "The Rust of SQL remains to be invented. I would like to see it come."'
But would that actually be in the relational space, or do we need to move into graph, boots and all? David
On Mon, 19 Jul 2021 14:51:19 +1200, David McNab wrote:
But would that actually be in the relational space, or do we need to move into graph, boots and all?
“Relational” doesn’t have to mean SQL, since there is relational algebra, after all <https://en.wikipedia.org/wiki/Relational_algebra>. By the way, what’s the difference between a “graph” database and an old-style “network” database <https://en.wikipedia.org/wiki/Network_model>?
On Mon, 19 Jul 2021 at 15:19, Lawrence D'Oliveiro <ldo(a)geek-central.gen.nz> wrote:
By the way, what’s the difference between a “graph” database and an old-style “network” database <https://en.wikipedia.org/wiki/Network_model>?
https://stackoverflow.com/questions/5040617/what-is-the-difference-between-a... Or, better yet: https://raima.com/network-database-relational-db-and-graph-db-compared/#6 Anyway, it's interesting that this topic should surface now. I've spent much of the last few months feeling the "four by two blows to the head" of SQL, and ORM layers can only eliminate part of the pain. So I'm thinking of reviving a certain graph-over-SQL layer I wrote a few years back :) Cheers D
participants (3)
-
David McNab -
Lawrence D'Oliveiro -
Peter Reutemann