> 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
js8 2 hours ago [-]
> 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.
randomNumber7 1 hours ago [-]
SQL is not an imperative programming language.
adrian_b 21 minutes ago [-]
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.
srean 2 hours ago [-]
There was a good blog post on how the category theoretic ideas behind this applies to data frames
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.
js8 2 hours ago [-]
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.)
adrian_b 15 minutes ago [-]
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.
1 hours ago [-]
flying_sheep 3 hours ago [-]
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?
js8 2 hours ago [-]
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.
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:
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.
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
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.)
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.
The difference is more in theory than in practice.