11–20 of 177 posts
> Most importantly, SQL databases made supporting highly consistent ACID transactions easy. The default transaction isolation level for every major database is not ACID. Enabling the required serializability tends to make performance terrible, and so most don't.
At PRQL[1] we believe that SQL is a combination of two things:
1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL.
When people say that SQL will never die, they are usually thinking about Relational Algebra because SQL has been used interchangeably with that. With PRQL we agree that Relational Algebra is fundamental to thinking about data and we intend to keep that. However we've learned a lot about programming languages in the last 50 years and so PRQL is a revamp of SQL that brings the composability of functional languages and modern ergonomics to data transformations in order to improve the DX and UX of data scientists, data analysts and analytics engineers.
PRQL is simply a compiler that produces SQL so you can use it with whatever database you are currently using. It's completely open source with zero commercial associations and is deeply committed to staying that way forever.
> Most importantly, SQL databases made supporting highly consistent ACID transactions easy. The default transaction isolation level for every major database is not ACID. Enabling the required serializability tends to make performance terrible, and so most don't.
is trivial, no?
> ...tends to make performance terrible
I've heard this a lot but never seen any figures - anyone have any numbers/experience?
(edit: and most apps I've worked with didn't need serialisability, either because they were working with a snapshot of data or absolutely precise answers weren't needed)
1. You still have a schema in your code. With weak schemas it's now just harder to know if every record in your database conforms to it.
2. An ORM is a great tool for prototyping. R.g. have SQLAlchemy objects in code, run a command to generate a database migration; run the migration, and you have all your data guaranteed to be compatible with your latest code, and you didn't write any SQL.
Nitpick, but relational does not mean joins, it means tables/rows of tuples. A "relational document database" which is the slogan of Fauna it seems is a contradiction in terms.
That’s technically correct, and I think the author would say he’s aware of that definition. The article as I read it is trying to make a broader point, that there are underlying mathematical principles that inspired Codd’s relational model. I’ve never had cause to explore it, but my understanding is that there’s nothing in those principles that require tables/rows of tuples. One goal of the article seems to be to ins…
The relational model is a direct product of a set of mathematical principles Codd put together called relational algebra, which deals with sets of tuples called relations.
Nothing in the article addresses any of the mathematical underpinnings of the relational model. Its blowing smoke at an audience that it expects to know next to nothing about the topic.
> One goal of the article seems to be to inspire a curiosity in knowledgeable readers: what happens if you build a document database that also supports the same mathematical principles that inspired the relational model
The features of RDBMSs that they seem to be suggesting FQL supports are ACID transactions. While that's an important feature of RDBMSs, it isn’t the same thing as the mathematical principles addresses by the relational model, whether relational algebra or the more general set theory that inspires it. The article isn't directed at knowledgable readers.
Earlier quoted context omitted.
That’s technically correct, and I think the author would say he’s aware of that definition. The article as I read it is trying to make a broader point, that there are underlying mathematical principles that inspired Codd’s relational model. I’ve never had cause to explore it, but my understanding is that there’s nothing in those principles that require tables/rows of tuples. One goal of the article seems to be to ins…
A relation is by definition a set of tuples (informally called a table where the tuples are the rows). Codds relational database model adds the further constraint that nested tables are not allowed (first normal form), instead representing relationships through foreign keys. Codds motivation for disallowing nested tables is that it makes query languages much simpler. He develops relational algebra which is the founda…
Can anyone elucidate? Please don't shout that I'm wrong because there was something there in his first paper.
> Most importantly, SQL databases made supporting highly consistent ACID transactions easy. The default transaction isolation level for every major database is not ACID. Enabling the required serializability tends to make performance terrible, and so most don't.
that's presumably why the author said "made supporting... easy", not "is"?
Seems like a lot of what fauna does by storing documents isn’t really new, oracle, Postgres and others have provided this for a long time. I was really surprised by the performance of json queries [1], opens the doors to using Postgres as a client api cache, storing the payload in a table, and doing deserialization using (materialized) views. Difference seems to be the approach to minimize number of calls from your a…
On strong schemas and flexibility: 1. You still have a schema in your code. With weak schemas it's now just harder to know if every record in your database conforms to it. 2. An ORM is a great tool for prototyping. R.g. have SQLAlchemy objects in code, run a command to generate a database migration; run the migration, and you have all your data guaranteed to be compatible with your latest code, and you didn't write a…
Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…