Live data from Hacker News

PRQL – A proposal for a better SQL

github.com

31–40 of 302 posts

Re: PRQL – A proposal for a better SQL

#31

Do people still write SQL?

Yes, quite a lot I would imagine. I use it extensively at work and similarly sql heavy software companies in the past. That being said, I’ve also worked at places where they’ve avoided it like the plague – largely because few people were competent at it – and were moving away from relational DBs due to scale.

Re: PRQL – A proposal for a better SQL

#32
post #22

Earlier quoted context omitted.

There was this professor of language who would say "Do you think the question ('are carpets furniture?') tells you something about the ambiguity of the word carpet, or do you think it tells you something about the ambiguity in the world?" Similarly, I think joins are "tough" not because of the way SQL expresses them but because the logical possibilities of merging data from multiple tables are varied.

There is no such thing as a domain-agnostic SQL database that holds up under this kind of semantic scrutiny. I don't think that there ever could be. If you are rolling a SQL schema for a home improvement contractor, it is extraordinarily unlikely that their specific business would expect any scenarios in which carpets are sometimes known as furniture. Having a bounded context to operate within is what makes SQL magic…

The carpet discussion was simply to say that you can't take out all the complexity of a language if the domain it is meant to describe is complex. The language has a limit to how simple it can be.

I was not proposing a SQL database of carpets, or furniture, as a thought experiment.

Re: PRQL – A proposal for a better SQL

#35
For any who want this kind of pipelining way-of-writing-SQL that has the benefit of existing in live production databases today, I highly, highly recommend looking into Postgres' and Snowflake's LATERAL JOIN keyword.

https://heap.io/blog/postgresqls-powerful-new-join-type-late...

https://stackoverflow.com/questions/28550679/what-is-the-dif...

https://docs.snowflake.com/en/sql-reference/constructs/join-...

The TL;DR is that they allow you to reuse annotated and aggregated columns in an incredibly elegant way. Compared to OP's proposal, you still do need to start the query with what columns you want to come out at the end, and normal SQL weirdnesses still apply - but it's far, far, easier when writing massive analytics queries to see the flow of variables from one stage to another.

Re: PRQL – A proposal for a better SQL

#36
Awesome! Would love to see an implementation. I worked on something similar over the Summer. It’s just relational algebra with pipes for composition. If you are interested, we could get an antlr grammar going and plug it into this basic execution engine to get a feel for the language.

- https://github.com/RCHowell/Sift - https://github.com/RCHowell/Sift/blob/main/src/main/kotlin/c...

Re: PRQL – A proposal for a better SQL

#37

Do people still write SQL?

I prefer to write SQL as most alternatives ether have runtime surprises or require more roundtrips to the database. I mostly work on line-of-business software, so if I was doing simple CRUD apps I might have a different opinion.

Re: PRQL – A proposal for a better SQL

#40

My thought is that joins are the tough part of the SQL learning curve, but I don't see much in here that reduces the complexity of joins.

There was this professor of language who would say "Do you think the question ('are carpets furniture?') tells you something about the ambiguity of the word carpet, or do you think it tells you something about the ambiguity in the world?" Similarly, I think joins are "tough" not because of the way SQL expresses them but because the logical possibilities of merging data from multiple tables are varied.

Then make some cases easier and fall back to the SQL we already have for the rest?
Post reply on HN