Father of SQL says yes to NoSQL
- Reference: 1715342409
- News link: https://www.theregister.co.uk/2024/05/10/sql_cocreator_nosql/
- Source link:
Speaking to The Register as SQL marks its 50th birthday, Donald Chamberlin, who first proposed the language with IBM colleague Raymond Boyce in a [1]1974 paper [PDF], explains that NoSQL databases and their query languages could help perform the tasks relational systems were never designed for.
"The world doesn't stay the same thing, especially in computer science," he says. "It's a very fast, evolving, industry. New requirements are coming along and technology has to change to meet them, I think that's what's happening. The NoSQL movement is motivated by new kinds of applications, particularly web applications, that need massive scalability and high performance. Relational databases were developed in an earlier generation when scalability and performance weren't quite as important. To get the scalability and performance that you need for modern apps, many systems are relaxing some of the constraints of the relational data model."
[2]
NoSQL takes a variety of forms, each designed to address different challenges. Popular document databases are based on the open JSON standard and broadly try to get around the schema constraints of the RDBMS. They include MongoDB, Couchbase, and Amazon's DynamoDB. Key-value stores are said to offer flexibility and speed. Examples include Aerospike, Memcached, and [3]Redis , which is frequently used as an internet application cache, and as such is the most popular database on AWS. Graph databases are designed to represent networks of relationships as edges and nodes, and include systems like Neo4j and TigerGraph.
[4]
[5]
Debate has raged among database experts, some of whom see the need for the NoSQL approach, while others argue the properties of NoSQL systems can be absorbed as features in relational systems. Most popular relational systems now support JSON documents, for example, while graph-style queries are possible in Oracle and PostgreSQL.
However, Chamberlin sees a need for NoSQL to support modern applications. For example, traditional relational systems guarantee asset record reserves on transactions to provide immediate consistency, he says.
[6]
"To get higher performance, now we're often distributing data over clusters of machines," he tells us, "and we're satisfied with eventual consistency, meaning we can be patient, it will take a little while for all the machines to catch up. That's necessary sometimes in highly scaled environments."
A long-time IBMer, Chamberlin is now semi-retired, but finds time to fulfill a role as a technical advisor for NoSQL company Couchbase.
[7]Oracle's database family gets trendy AI makeover
[8]Lakehouse dam breaks after departure of long-time Teradata CTO
[9]Graph databases speaking the same language after ISO gives GQL the nod
[10]Valkey publishes release candidate and attracts new backer
In the role, he has become an advocate for a new query language designed to overcome the " [11]impedance mismatch " between data structures in the application language and a database, he says.
UC San Diego professor Yannis Papakonstantinou has [12]proposed SQL++ to solve this problem, with a view to addressing impedance mismatch between heavily object-based JavaScript, the core language for web development and the assumed relational approach embedded in SQL.
Like C++, SQL++ is designed as a compatible extension of an earlier language, SQL, but is touted as better able to handle the JSON file format inherent in JavaScript.
[13]
Couchbase and AWS have adopted the language, although the cloud giant calls it [14]PartiQL .
Chamberlin's [15]2019 paper [PDF] for Couchbase introduces SQL++ and SQL:2016, and looks at some example queries written in both languages to compare the two.
But SQL++ is no replacement for SQL, he says, rather it's complementary.
"I don't think SQL is going to go away," he says. "A large part of the world's business data is encoded in SQL, and data is very sticky. Once you've got your database, you're going to leave it there. Also, relational systems do a very good job of what they were designed to do. We have these very high quality open source implementations in MySQL, PostgreSQL, and SQLite.
"These are all very robust, fully featured, reliable SQL implementations. They have large user communities, and if you're a startup company that wants to sell shoes on the web or something, you're going to need a database, and one of those SQL implementations will do the job for free. I think relational databases and the SQL language will be with us for a long time." ®
Look out for The Register's History of the SQL language, including more from the interview with Don Chamberlin, coming up next week.
Get our [16]Tech Resources
[1] https://web.archive.org/web/20070926212100/http://www.almaden.ibm.com/cs/people/chamberlin/sequel-1974.pdf
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zj5Enxcu22yZfvU05E0a0QAAAEM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2024/04/30/bruce_perens_post_open_license/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zj5Enxcu22yZfvU05E0a0QAAAEM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zj5Enxcu22yZfvU05E0a0QAAAEM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zj5Enxcu22yZfvU05E0a0QAAAEM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2024/05/04/oracle_database_rebrand/
[8] https://www.theregister.com/2024/05/01/teradata_embraces_otfs/
[9] https://www.theregister.com/2024/04/24/gql_iso_recognition/
[10] https://www.theregister.com/2024/04/18/valkey_publishes_release_candidate/
[11] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch
[12] https://arxiv.org/abs/1405.3631
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zj5Enxcu22yZfvU05E0a0QAAAEM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://aws.amazon.com/blogs/opensource/announcing-partiql-one-query-language-for-all-your-data/
[15] https://info.couchbase.com/rs/302-GJY-034/images/Comparing_Two_SQL_Based_Approaches_WP.pdf
[16] https://whitepapers.theregister.com/
Re: The long view
I envy you. I have copy of one of Chris Date's books with me and was lucky enough to meet Fabian Pascal to discuss how the industry constantly seeks to undermine the advantages of a rigorous understanding by pushing their substandard but shiny implementations. I recently revisited a fairly standard task (essentially filling missing rows in a calculated data set) that I personally can't easily solve in a single query (I find subqueries difficult to think with) but which became crystal clear through the use of views and CTEs.
It's been suggested that SQL was deliberately hobbled by vendors to push their products, in ways we've seen with other standards such as from C++ to HTML. This gets even worse when you read the literature that is supposed to teach you about relational databases, but which almost invariably promote particular implementations and their assumptions.
There are also several misconceptions about both relational databases and NoSQL. Relational databases are often not just more reliable because of integrity constraints, but also more powerful, because of the power of the underlying relational calculus. The "o", meaning "(not) only" is the key letter in NoSQL and is the get-out clause when you want to work with ephemeral data, and can live without integrity. But this is not really much different to a data processing pipeline where you mine data as it enters the system. There's nothing special with the databases that can't be done with a relational store if you disable some of the constraints. But in nearly all situations losing integrity will impose the highest cost on your work.
Scalability for relational databases using clusters has been possible for years. It takes some work to get right and will cost something but far less than surrendering data integrity will when it inevitably comes to bite.
Re: The long view
The *intent* of SQL was to simplify the query language aka lower the entry bar.
Got to pick the right tool for the job
NoSQL has it's strengths but it also has weaknesses, too. Same for Relational DB's, transactional DB's etc.
Issues with NoSQL is they don't scale to the same extent as the more traditional DB's. But they're a hell of a lot better at handling unstructured data (it's what they're designed for). If you want transactional data or data security, it's not as good (these have to be handled before hitting the DB) where as a well designed relational DB has it baked in.
So, depending on what you need the DB for - that dictates which approach to take.
Just not MySQL. Please, not MySQL... just... no.
Unasked question
Did nobody think to ask the guy "Is it ess cue ell, sequel or squeal?"
Re: Unasked question
Maybe it's not even an answerable question.
Re: Unasked question
I was wondering about that the other day, and then I... SQUIRREL!
The long view
Its probably worth remembering that SQL isn't the relational model (or vice versa.) In Michael Stonebreaker's Ingres Papers the original Ingres query language QUEL, I think, was claimed to be superior to the SQL if that time.
Chamberlain's points about non SQL databases in a distributed and massively scaled environment are probably valid. I don't have the knowledge or experience to say.
I have Codd's original paper in an ACM anthology which is still worth reading for its clarity of vision.
The Ingres Papers are worth reading just to realize what they were doing, when and with what. Not much since then is really new.