Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relational is more than SQL

fauna.com

Post reply on HN
Print view View original

51–60 of 177 posts

Re: Relational is more than SQL

#51

Post by jug »

ilyt wrote: post #50
jug wrote: post #38

Earlier quoted context omitted.

At least superficially this looks a lot like C# LINQ to me in terms of structure and database independence (as for EF Core + LINQ). It’s in my top 3 features of that language. https://www.tutorialsteacher.com/linq/sample-linq-queries Edit: Shortened to link due to formatting issues

> Iterating through that would use lazy evaluation by default, returning row by row from the db as needed. That's... not an advantage in most cases

Well, it’s an option when and IIRC a default. Here’s a discussion https://stackoverflow.com/questions/31366236/lazy-loading-vs...

Re: Relational is more than SQL

#52

Post by jimwhite42 »

bazoom42 wrote: post #45
jimwhite42 wrote: post #31

Earlier quoted context omitted.

Date and Darwen (spritual successors to Codd?), have a relational theory which allows nested relation values and I think it doesn't contradict the motivation behind first normal form, and it isn't hierarchical in the pre-relational database sense. I think they cleaned up Codd's ideas very effectively.

The motivation behind first normal form is to keep the query language simple and powerful at the same time. Allowing nested tables would require extensions to the query language but wouldn’t give any additional expressive power since you can already express the same relationships using foreign keys. Also I dont see how it isn’t hierachical? Nested tables create a hierachical structure just like nested records in a hi…

> Also I dont see how it isn’t hierachical? Nested tables create a hierachical structure just like nested records in a hierachical database. What is the difference?

I haven't seen any reasonable uses of nested relations in base relvars, I think they are slightly different to nested records if you can query them declaratively instead of via imperative looking nested loop code.

But nested tables can be used in queries - the group and ungroup operators are pretty useful. It's a straightforward way to define (and even implement) group by aggregates for instance.

> Allowing nested tables would require extensions to the query language but wouldn’t give any additional expressive power since you can already express the same relationships using foreign keys.

Everything is a tradeoff. There are lots of queries that you can write using correlated subqueries in SQL, but I think would be much simpler if you could use group and ungroup.

I don't really follow your last paragraph at all. I would much rather use Date and Darwen's relational theory than Codd's. I think they have the right amount of respect for Codd, and definitely aren't shy to highlight where they differ from him, or to contradict him.

Do you have an example of them trying to redefine something in the way you say?

Re: Relational is more than SQL

#53

Post by snthpy »

snthpy wrote: post #12

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…

For those interested who want to learn more, we have a number of presentations coming up at conferences on three continents:

- [QCon SF, October 2nd, San Francisco, USA: ](https://qconsf.com/presentation/oct2023/prql-simple-powerful...)

- [PyconZA, October 5th, Durban, South Africa: ](https://za.pycon.org/)

- [Community over Code (ApacheCon), October 9th, Halifax, Canada: ](https://communityovercode.org/schedule-list/#FT005)

- [data2day, October 12th, Karlsruhe, Germany: ](https://www.data2day.de/veranstaltung-21353-0-prql-a-modern-...)

Re: Relational is more than SQL

#54

Post by ghusbands »

_a_a_a_ wrote: post #23
ghusbands wrote: post #21

Earlier quoted context omitted.

I've heard multiple accounts of people being taken by surprise by this and by how transaction isolation actually works in databases and not finding it at all easy to correct it. A famous one is https://blog.codinghorror.com/deadlocked/ (On your edit: The problem is not knowing when you're being hit by it. Even just maintaining a limit on total size of uploaded files or such, for example, is nontrivial under default i…

On your first para I'm not remotely sympathetic. They are using a complex, sophisticated tool without understanding it. They got what they deserved. Particularly telling is this ridiculous quote "I'm a little disappointed that SQL Server treats our silly little web app like it's a banking application". Edit: so, they wanted even more lax integrity constraints by default? FFS And, BTW, deadlocks can most definitely ha…

You're expecting a very high level of expertise for a tool that so many use incidentally. Most don't actually know how transaction isolation works, especially as the fine detail varies between databases. It's incredibly common to believe that databases actually are ACID by default and that is repeated far and wide.

For the last, I was pointing out that people don't necessarily know when they hit race conditions or other transaction isolation faults; they're one of the hardest things to debug or notice. It would be easy to believe that a transaction that confirms a file update would not take a user over their quota and then updates the file would, per ACID, actually ensure the user doesn't exceed their quota. But the default transaction isolation levels don't provide that.

Re: Relational is more than SQL

#55

Post by snthpy »

roenxi wrote: post #44
snthpy wrote: post #12

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…

Great project, wish you all the best. Anything to try and unseat SQL from common use (we can all wish for the day we run PostgrespostSQL in production). At the moment the project is probably going to lose people because it isn't obvious how to get started - many SQL beginners don't know what a compiler is and will get confused by the docs. For the sake of their sanity, it'd be worth considering putting an example of…

Thank you for your feedback. That's really valuable!

We have the [PRQL Playground](https://prql-lang.org/playground/) exactly for that purpose.

We'll try and make it more prominent on the front page. I've also felt that we should have a "Getting started" page and will push that as a priority.

Re: Relational is more than SQL

#56

Post by snthpy »

frogulis wrote: post #28
snthpy wrote: post #12

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…

Pretty cool, your description got my click. I particularly enjoy that a filter is a filter before and after grouping. One thing, the "showcase" section is not usable for me on mobile. The code box does not fit on the screen horizontally and I can't scroll right to see the remainder of it.

Thank you for the feedback. I'll let the team know.

We definitely want people on all devices to be able to learn about the project.

Re: Relational is more than SQL

#57

Post by snthpy »

jug wrote: post #38
snthpy wrote: post #12

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…

At least superficially this looks a lot like C# LINQ to me in terms of structure and database independence (as for EF Core + LINQ). It’s in my top 3 features of that language. https://www.tutorialsteacher.com/linq/sample-linq-queries Edit: Shortened to link due to formatting issues

LINQ is definitely one of the big influences along with many other great projects that form the prior art in this space.

See this section in our FAQ: https://prql-lang.org/faq/#:~:text=Something%20here%20remind...

Re: Relational is more than SQL

#58

Post by snthpy »

danielvaughn wrote: post #20
snthpy wrote: post #12

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…

That first PRQL code sample is wonderfully readable.

Awesome! That's what we're hoping for. Great to hear that you find it wonderfully readable!

Re: Relational is more than SQL

#59

Post by snthpy »

hiAndrewQuinn wrote: post #34
snthpy wrote: post #12

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…

This is tremendous. I'm curious to know if a CLI `prqlite3` exists which wraps around the `sqlite3` CLI many of us know and love.

Thank you.

The CLI usability was one of the aims behind [prql-query (pq)](https://github.com/prql/prql-query/). sqlite integration was on the roadmap but unfortunately that project has been largely unmaintained by me for the past 6 months. (This is just referring to prql-query and not PRQL which is under very active development.)

I'm working on a new project which will do exactly this (and a lot more!) which I hope to release next week. I'll drop the link here when that's ready.

Re: Relational is more than SQL

#60

Post by snthpy »

spion wrote: post #41
snthpy wrote: post #12

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…

How is the language server support?

We do have grammars for many editors. I'm not sure about LSP off the top of my head but you should find something in the docs under "Integrations".

There is also a VSCode extension: https://marketplace.visualstudio.com/items?itemName=prql-lan...

Post reply on HN