> CQL is not a database management system: it neither stores nor updates data.
The same could be said for SQL. How does CQL differ from SQL? If I squint my eyes just a tiny amount, these ideas become really difficult to separate. I was always under the impression that the relational model is based upon many concepts studied in category theory. To my mind, all of the following things are overlapping parts of the exact same monster:
Set theory
Category theory
Graph theory
Type theory
Discrete mathematics
Relational algebra
Relational calculus
Relational modeling
An actual sql schema
Most attempts to replace/improve SQL derive from the fact SQL was a poorly conceived and designed interface, that originally was meant to be a very small DSL for end users, but unfortunately, was allowed to become a poor, complicated, confusing mess for app developers:
SQL is not an orthogonal language... This is because, in the early days, Ray Boyce and I did not think we were designing a language for programmers. ..
As it turned out, Ray and I were wrong about the predominant usage of SQL...
(same problem from JS, php, etc: Creators don't anticipate that developers will suffer and torture their needs with such anemic ideas!)
---
So the #1 thing any actual replacement or alternative to SQL is how actually become a good language for development, so it is actually composable, can be actually be used to reason about it, has minimal foot guns, etc.
There is a lot of misunderstanding and pushback, similar to how people in the past fight improvements over JS/C/C++ until typescript, rust comes.
The main innovation here seems to be compile time checking of that foreign keys are respected but that is a thing that can be added to SQL and there is at least one proposal for doing so. So I do not really see anything fundamentally different from SQL.
Since it took bit of time and multiple broken links to find: https://categoricaldata.net/examples has links to a lot of info about CQL for learning/comparing/etc.
(edit: in retrospect, this is just the "getting started" header link, despite the URL)
Unfortunately none that I've followed seems to do much to describe much of anything except the math foundations. They might cover pieces of syntax, but not how to use or think about them, and they seem to be rather excited about the data-generating features that I can't imagine anyone using outside tech demos (unless that's the only insert method? what about update?) :/
(edit 2: you can't even rely on the manual apparently, I'm fairly confident https://categoricaldata.net/help/Demo.html (manual -> examples -> demo) won't work because it has no schema definition for `Animal`. and it like all the others I've checked are little more than syntax and output, no real explanation)
SQL is like Java, CQL is like Haskell. SQL has been around and used in production. CQL is a research language, possibly cleaner foundation but YMMV.
The math fields you list are connected, but whether they are the same monster - again it's kinda like claiming all programming languages and implementations are the same (Turing-complete?) monster.
Most of SQL is not imperative, but it certainly also includes some imperative commands.
Inserting a new row into an existing table is an imperative command, which may be the most frequently used of the SQL features, in certain applications concerned with recording transactions.
Only the subset of SQL that is used for queries can be said to not be an imperative programming language.
No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless.
Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.
Imperative languages such as C/C++ specify "microtransactions" - an ordering over memory accesses (including (de)allocations) within some statement or group of statements.
Compilers are free to rearrange these accesses if the final result is same as if executed by these ordered microtransactions.
Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.
printf("Hello world!");
also does not tell anything to the system about how to accomplish this.
Anyone who claims that an SQL command like insert a row, create a table or destroy a table is not imperative, is just plainly wrong.
Even in real life, when humans communicate commands to each other, from where the term "imperative" comes, the commands normally do not tell anything to the recipient about how to accomplish the order, they just name the action, because it is supposed that whoever receives the command knows how to do it.
After programming languages were invented there was a clear partition between commands a.k.a. imperative statements, expressions and definitions a.k.a. declarations ("definition" and "declaration" were originally synonymous terms, "declaration" being the ALGOL 60 term and "definition" being the CPL term; the use of the 2 words with different meanings, like in C, where it is required by a defect of the compiler, which needs additional declarations besides a definition, is only recent.)
Later the meanings of these terms have become muddled by their careless use by many authors, which usually had political reasons, i.e. because they somehow considered the words "imperative" or "command" as shameful, they attempted to present their pet languages as purely functional or purely declarative, so they twisted the words in various ways, despite the fact that any practical program must contain imperative parts, not only functional or declarative parts.
C#,C++, Java seems imperative. You are in control? But you aren't really telling it how to move values between registers, the compiler is making a million decisions for you on how the computer will execute that 'imperative' code. Just like SQL isn't really telling the DB how to do it either..
It's really a matter of degrees though. You're waving away a big part of the big sell of a relational database as proposed by Codd, which is that the user need not "know" the structure of the data in order to formulate operations on it because there's a consistent set-oriented model that can be used with a bunch of different physical storage forms but also the very sequence of relational operations against it can be re-ordered / restructured without the user knowing. And that the same data can be accessed in N number of ways that don't require changing the underlying storage. In theory. In practice SQL databases are only sort-of there.
Contrast that if I create a class/object/field structure/hierarchy in Java, or put a HashMap somewhere with a certain set of keys, I've written something in stone which requires significant refactoring if the data needs to be accessed from a different direction.
This just exposes how weak this definition of declarative is, I think. Or how it's carrying two meanings here.
What you're really talking about is one of the things Codd wanted to emphasize: representational independence. Which actually was the primary thrust of his famous paper: the user should not need to know how the data is stored in order to use or manipulate it.
The other thing that people are talking about with "declarative" is probably another level up in abstraction. Talking about the business logic or problem in terms that are closer to logic than a sequence of instructions, and then letting the machine sort out what those steps are.
Consider in a Datalog users don't customarily perform DDL type operations; they declare data rules and the system decides the form of the underlying relations. That's a small step up the declarative ladder from SQL, even if it's somewhat analogous to "create view".
So I think there's a blurry definitional line between the two. But I don't think your very blunt "No." is doing much to help clear that up?
I know very little about databases, but I work heavily with category theory, so fwiw: I think the main benefit is composition. The edge over SQL shows up when you combine schema mappings - a mapping is a functor, so when you migrate data along it the constraints come with it by construction, and you don't end up writing ETL and hoping integrity held.
As best as I can tell (but i really dont know much about databases) it's probably a narrow advantage - storage and everyday queries still go to Codd's model - but for stitching schemas together it seems like it could work.
I'm using similar math for automated formal verification, where this approach is what makes it tractable.
We have not yet converged on a best (or even adequate) way to present a structured mountain of information to AI, not already in its training corpus.
AI agents fielded by major AI players still fail at the basic task of providing immediate and correct support for use of the current versions of their products. If a programming language is too new to have adequate representation in the training corpus, there isn't an accepted standard way to provide a reference manual targeting AI agents. Even the best way to include documentation in a large project so new AI agents can take over is controversial. A pile of linked markdown files really isn't an answer, less structured than a codebase itself, that AI is good at navigating.
Other HN posts have discussed using SQL as a backbone for the AI "mind mapping" support we need for AI more critically than for ourselves.
I was hoping that CQL could be an answer to this. Perhaps, but not its current primary goal.
> Reduce risk of failure through artificial intelligence. CQL contains an embedded automated theorem prover that guarantees the correctness of CQL programs.
Man, it's a rough environment right now marketing-wise. I don't know if they're contractually obligated to say the funny magic words, but the term AI is nearly entirely meaningless at this point. Akin to saying "behold my mighty calculator app: it prevents divisions by zero through artificial intelligence!"
Huh, I read the pitch differently. As "reduce risk of (failure through artificial intelligence)," not as "(reduce risk of failure) through artificial intelligence."
Maybe that's my bias since that's what I'm working on, but it's a big benefit to have stronger compiler guarantees of correctness so that an LLM can't screw things up as much. No BSing that it works when the compiler requires proof.
It's what we used to call AI back in the 1970s and 1980s which has advanced a whole lot with little awareness. That is, people thought 10,000 rules was a lot of rules in 1998 and now you can work with 10,000,000 rules. And theorem provers, SAT and SMT all got vastly better.
Since Codd's paper showed that the relational model dominates other approaches (for data storage) I would expect a paper that shows categorical database are not affected by this and what benefit they have.
While the relational model is claimed to be based on relations, the vast majority of the "relations" used in practice are functions, not general relations.
A general relation exists only between the columns of a table that are included in a multi-column primary key.
All columns that are not part of the primary key are functions of the primary key.
Most tables used in practice use a single column as the primary key, which is frequently just a number or a UUID. Most databases contain only tables that are functions, without any table that contains general relations.
The most frequently used kinds of joins are just function compositions.
Query 1 from TPC-DS creates a multi-column relation by using GROUP BY. Which relation is then partially constrained by different columns from different tables.
Thanks for the sharing. It looks interesting but I did not dive deep into it. Just wonder how is it different from SQL trigger which can also ensure integrities?
> CQL is not a database management system: it neither stores nor updates data.
The same could be said for SQL. How does CQL differ from SQL? If I squint my eyes just a tiny amount, these ideas become really difficult to separate. I was always under the impression that the relational model is based upon many concepts studied in category theory. To my mind, all of the following things are overlapping parts of the exact same monster:
> How does CQL differ from SQL?
Most attempts to replace/improve SQL derive from the fact SQL was a poorly conceived and designed interface, that originally was meant to be a very small DSL for end users, but unfortunately, was allowed to become a poor, complicated, confusing mess for app developers:
https://cacm.acm.org/research/50-years-of-queries/
(same problem from JS, php, etc: Creators don't anticipate that developers will suffer and torture their needs with such anemic ideas!)---
So the #1 thing any actual replacement or alternative to SQL is how actually become a good language for development, so it is actually composable, can be actually be used to reason about it, has minimal foot guns, etc.
There is a lot of misunderstanding and pushback, similar to how people in the past fight improvements over JS/C/C++ until typescript, rust comes.
But, oh boy, SQL need their typescript!
The main innovation here seems to be compile time checking of that foreign keys are respected but that is a thing that can be added to SQL and there is at least one proposal for doing so. So I do not really see anything fundamentally different from SQL.
https://keyjoin.org/
Full disclosure: I am one of the co-authors of this paper and an associated patch implenting it in PostgreSQL that we have proposed.
I am happy to see more people than us think this is useful.
Here is a tl;dr as well: https://keyjoin.org/tldr.html
Since it took bit of time and multiple broken links to find: https://categoricaldata.net/examples has links to a lot of info about CQL for learning/comparing/etc.
(edit: in retrospect, this is just the "getting started" header link, despite the URL)
Unfortunately none that I've followed seems to do much to describe much of anything except the math foundations. They might cover pieces of syntax, but not how to use or think about them, and they seem to be rather excited about the data-generating features that I can't imagine anyone using outside tech demos (unless that's the only insert method? what about update?) :/
(edit 2: you can't even rely on the manual apparently, I'm fairly confident https://categoricaldata.net/help/Demo.html (manual -> examples -> demo) won't work because it has no schema definition for `Animal`. and it like all the others I've checked are little more than syntax and output, no real explanation)
> How does CQL differ from SQL?
SQL is like Java, CQL is like Haskell. SQL has been around and used in production. CQL is a research language, possibly cleaner foundation but YMMV.
The math fields you list are connected, but whether they are the same monster - again it's kinda like claiming all programming languages and implementations are the same (Turing-complete?) monster.
SQL is not an imperative programming language.
DROP TABLE ?
Most of SQL is not imperative, but it certainly also includes some imperative commands.
Inserting a new row into an existing table is an imperative command, which may be the most frequently used of the SQL features, in certain applications concerned with recording transactions.
Only the subset of SQL that is used for queries can be said to not be an imperative programming language.
No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless.
Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.
Imperative languages such as C/C++ specify "microtransactions" - an ordering over memory accesses (including (de)allocations) within some statement or group of statements.
Compilers are free to rearrange these accesses if the final result is same as if executed by these ordered microtransactions.
Consider loop fusion, loop splitting and/or loop skewing.
Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.
also does not tell anything to the system about how to accomplish this.Anyone who claims that an SQL command like insert a row, create a table or destroy a table is not imperative, is just plainly wrong.
Even in real life, when humans communicate commands to each other, from where the term "imperative" comes, the commands normally do not tell anything to the recipient about how to accomplish the order, they just name the action, because it is supposed that whoever receives the command knows how to do it.
After programming languages were invented there was a clear partition between commands a.k.a. imperative statements, expressions and definitions a.k.a. declarations ("definition" and "declaration" were originally synonymous terms, "declaration" being the ALGOL 60 term and "definition" being the CPL term; the use of the 2 words with different meanings, like in C, where it is required by a defect of the compiler, which needs additional declarations besides a definition, is only recent.)
Later the meanings of these terms have become muddled by their careless use by many authors, which usually had political reasons, i.e. because they somehow considered the words "imperative" or "command" as shameful, they attempted to present their pet languages as purely functional or purely declarative, so they twisted the words in various ways, despite the fact that any practical program must contain imperative parts, not only functional or declarative parts.
"how to accomplish the thing."
I always thought this was splitting hairs.
C#,C++, Java seems imperative. You are in control? But you aren't really telling it how to move values between registers, the compiler is making a million decisions for you on how the computer will execute that 'imperative' code. Just like SQL isn't really telling the DB how to do it either..
It's really a matter of degrees though. You're waving away a big part of the big sell of a relational database as proposed by Codd, which is that the user need not "know" the structure of the data in order to formulate operations on it because there's a consistent set-oriented model that can be used with a bunch of different physical storage forms but also the very sequence of relational operations against it can be re-ordered / restructured without the user knowing. And that the same data can be accessed in N number of ways that don't require changing the underlying storage. In theory. In practice SQL databases are only sort-of there.
Contrast that if I create a class/object/field structure/hierarchy in Java, or put a HashMap somewhere with a certain set of keys, I've written something in stone which requires significant refactoring if the data needs to be accessed from a different direction.
This just exposes how weak this definition of declarative is, I think. Or how it's carrying two meanings here.
What you're really talking about is one of the things Codd wanted to emphasize: representational independence. Which actually was the primary thrust of his famous paper: the user should not need to know how the data is stored in order to use or manipulate it.
The other thing that people are talking about with "declarative" is probably another level up in abstraction. Talking about the business logic or problem in terms that are closer to logic than a sequence of instructions, and then letting the machine sort out what those steps are.
Consider in a Datalog users don't customarily perform DDL type operations; they declare data rules and the system decides the form of the underlying relations. That's a small step up the declarative ladder from SQL, even if it's somewhat analogous to "create view".
So I think there's a blurry definitional line between the two. But I don't think your very blunt "No." is doing much to help clear that up?
For all practical purposes, it very much is, consider random number generation.
While agree with the main statement, I don’t understand the point about RNG. You don’t need Turing-completeness nor imperativeness for RNG.
There was a good blog post on how the category theoretic ideas behind this applies to data frames
What Category Theory Teaches Us About DataFrames https://mchav.github.io/what-category-theory-teaches-us-abou...
Discussed on HN at (67 comments)
https://news.ycombinator.com/item?id=47561426
I know very little about databases, but I work heavily with category theory, so fwiw: I think the main benefit is composition. The edge over SQL shows up when you combine schema mappings - a mapping is a functor, so when you migrate data along it the constraints come with it by construction, and you don't end up writing ETL and hoping integrity held.
As best as I can tell (but i really dont know much about databases) it's probably a narrow advantage - storage and everyday queries still go to Codd's model - but for stitching schemas together it seems like it could work.
I'm using similar math for automated formal verification, where this approach is what makes it tractable.
I haven't used CQL but this is how the advantages have been described to me as well.
We have not yet converged on a best (or even adequate) way to present a structured mountain of information to AI, not already in its training corpus.
AI agents fielded by major AI players still fail at the basic task of providing immediate and correct support for use of the current versions of their products. If a programming language is too new to have adequate representation in the training corpus, there isn't an accepted standard way to provide a reference manual targeting AI agents. Even the best way to include documentation in a large project so new AI agents can take over is controversial. A pile of linked markdown files really isn't an answer, less structured than a codebase itself, that AI is good at navigating.
Other HN posts have discussed using SQL as a backbone for the AI "mind mapping" support we need for AI more critically than for ourselves.
I was hoping that CQL could be an answer to this. Perhaps, but not its current primary goal.
> Reduce risk of failure through artificial intelligence. CQL contains an embedded automated theorem prover that guarantees the correctness of CQL programs.
Man, it's a rough environment right now marketing-wise. I don't know if they're contractually obligated to say the funny magic words, but the term AI is nearly entirely meaningless at this point. Akin to saying "behold my mighty calculator app: it prevents divisions by zero through artificial intelligence!"
Huh, I read the pitch differently. As "reduce risk of (failure through artificial intelligence)," not as "(reduce risk of failure) through artificial intelligence."
Maybe that's my bias since that's what I'm working on, but it's a big benefit to have stronger compiler guarantees of correctness so that an LLM can't screw things up as much. No BSing that it works when the compiler requires proof.
I had to read it twice to come to that conclusion. Maybe the prima facie ambiguity is intentional.
It's what we used to call AI back in the 1970s and 1980s which has advanced a whole lot with little awareness. That is, people thought 10,000 rules was a lot of rules in 1998 and now you can work with 10,000,000 rules. And theorem provers, SAT and SMT all got vastly better.
Since Codd's paper showed that the relational model dominates other approaches (for data storage) I would expect a paper that shows categorical database are not affected by this and what benefit they have.
My (amateur) take. CDB model (based on functions) has three advantages over RDB model (based on relations):
1. Easier modelling sum types (inheritance) due to duality.
2. Better handling of null due to labelled null.
3. Better foundation of elementary types (they're just another table ids). (Column stores often do that already, if your question is about storage.)
While the relational model is claimed to be based on relations, the vast majority of the "relations" used in practice are functions, not general relations.
A general relation exists only between the columns of a table that are included in a multi-column primary key.
All columns that are not part of the primary key are functions of the primary key.
Most tables used in practice use a single column as the primary key, which is frequently just a number or a UUID. Most databases contain only tables that are functions, without any table that contains general relations.
The most frequently used kinds of joins are just function compositions.
While it is true on the schema level, it is not true at the query level.
The most frequently used kind of join is a general relation.
[1] https://github.com/agirish/tpcds/blob/master/query1.sql
Query 1 from TPC-DS creates a multi-column relation by using GROUP BY. Which relation is then partially constrained by different columns from different tables.
Thanks for the sharing. It looks interesting but I did not dive deep into it. Just wonder how is it different from SQL trigger which can also ensure integrities?
It's not much really, CDBs are based on foreign key relationships as a fundamental building block, rather than on relation.
The difference is more in theory than in practice.
Not to be confused with https://cql.hl7.org/ which is the CQL I know of.
For me, CQL will always mean Cassandra Query Language https://cassandra.apache.org/doc/4.0/cassandra/cql/