Relational is more than SQL • Hacker News Board

Re: Relational is more than SQL

#141

Post by OJFord » Sun, Sep 17, 2023, 12:19 AM UTC

wackget wrote: post #87

ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

Yeah the syntax comparison is deliberately misleading. They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines. # PRQL from employees select {id, first_name, age} sort age take 10 # Misleading SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 # Actual SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 The join example is similarly deceptive: # PRQL from employe…

Also there's no need to capitalise, so the 4 lines vs. 4 lines is actually just 'order by & limit' vs. 'sort & take'. NBD really, but it's probably nicer in more complex examples.

But I wanted about this the last time PRQL was submitted in its own right - https://news.ycombinator.com/item?id=36869376 - so I'll leave it there!

Re: Relational is more than SQL

#142

Post by maximilianroos » Sun, Sep 17, 2023, 1:04 AM UTC

maximilianroos wrote: post #132

lolinder wrote: post #126

Earlier quoted context omitted.

> We would take a PR for the first example if folks think that's better spacing. ... we'd take a PR on anything that is equivalent. "We'd take a PR" is a great line for someone who's already sold on the concept, but it's not super helpful for flaws in your marketing. Reading OP, it doesn't sound like they trust you enough to find it to be worth their time fixing your examples for you.

Yes, this is fair. Though I'm not sure how to find consensus on what is the best representation of SQL without asking folks to make a reviewable suggestion. I had thought the examples are currently in their clearest state — I definitely don't think it's obvious that removing line-breaks makes it look clearer (which is the full extent of the feedback IIUC...)

I opened an issue on this here: https://github.com/PRQL/prql/issues/3518

Re: Relational is more than SQL

#143

Post by naasking » Sun, Sep 17, 2023, 1:40 AM UTC

probablypower wrote: post #75

herodoturtle wrote: post #3

This is a very interesting way to promote a product, credit to the author (who is an industry veteran it seems). I had no idea what Fauna was. I just clicked the link here because the title caught my eye (I work with databases quite a bit). The opening paragraph immediately grabbed my attention - "My first deep dive into SQL was in 1987, just before I became the first technical person at Microsoft to work on SQL Serv…

This is interesting, because I have the exact opposite response to these sorts of articles. I think any bias or personal interest should be declared upfront in media (articles, videos, podcasts, ...) rather than appear as a 'common consumer' talking about a pain point in a relatable way. It really rubs me the wrong way when an article ends with a bait-and-switch, where you realise the entire article was manufactured…

> It really rubs me the wrong way when an article ends with a bait-and-switch, where you realise the entire article was manufactured to make you relate to their product's business case.

I'm not sure you have to take an adversarial interpretation of that tactic. If you don't find yourself agreeing with the setup, then you aren't a prospective customer, but if the article was informative to that point at least you now understand the existence of a domain that you're not aware of. Isn't that the point of reading technical articles? In the future, you might find yourself in that position after all.

Re: Relational is more than SQL

#144

Post by naasking » Sun, Sep 17, 2023, 1:46 AM UTC

j-a-a-p wrote: post #94

wackget wrote: post #87

Earlier quoted context omitted.

Yeah the syntax comparison is deliberately misleading. They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines. # PRQL from employees select {id, first_name, age} sort age take 10 # Misleading SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 # Actual SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 The join example is similarly deceptive: # PRQL from employe…

PRQL is a solution in search of a problem. Lacking such, the problem had to be fabricated.

SQL has many problems that PRQL ostensibly addresses. Query reuse, composability, abstraction and more.

Re: Relational is more than SQL

#145

Post by Too » Sun, Sep 17, 2023, 6:34 AM UTC

lolinder wrote: post #121

maximilianroos wrote: post #117

Earlier quoted context omitted.

[PRQL dev here] I agree with the sentiments, even if not the conclusion. SQL is omnipresent and is "fine" in a lot of cases. TypeScript is indeed a great example of the case; Kotlin too. I'd also add that databases are already adding PRQL support — ClickHouse has native support, there's a DuckDB extension, and folks are working on a Postgres extension. One thing I'll respectfully disagree with — "SQL is highly static…

Can you tell the shape of the result of ` ()` in Java by just reading it? No. Does that mean that Java can't be statically analyzed? Of course not! A static analysis system is not restricted to weird abstract constructs like `select `, it sees the complete picture and can come to conclusions based on the concrete code construct it's given. There's absolutely nothing stopping a SQL static analysis from recognizing tha…

Having some static constraints around makes it a lot easier to analyze though. Both for humans and compilers.

Otherwise you end up with situations like C++ templates, that can expand to anything. With long confusing errors, unable to distinguish if it’s an error in the usage, the definition or the call-site.

Re: Relational is more than SQL

#146

Post by remram » Sun, Sep 17, 2023, 9:47 AM UTC

ttfkam wrote: post #72

remram wrote: post #70

Earlier quoted context omitted.

It's just syntax, it compiles to SQL and runs on today's DBMS. It has no difference in speed or functionality.

(I couldn't help but notice you didn't comment on the difference in formatting in the examples.) Do you have examples of PRQL working with jsonpath? Generating JSON? Unnesting arrays? Returning ids from an INSERT or UPDATE without making a separate read query? Not trying to be argumentative. Honest question.

I am not affiliated in any way with the PRQL project. Those are great questions though, I hope we get an answer.

Re: Relational is more than SQL

#147

Post by seanhunter » Sun, Sep 17, 2023, 10:49 AM UTC

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…

SQL is based on relational calculus rather than relational algebra, which is why it's declarative. Relational algebra is built on fundamental relational operators (select, project, filter, product etc) which are imperatively applied. You can find out more about it here https://techdifferences.com/difference-between-relational-al...

Re: Relational is more than SQL

#148

Post by ako » Sun, Sep 17, 2023, 3:59 PM UTC

naasking wrote: post #144

j-a-a-p wrote: post #94

Earlier quoted context omitted.

PRQL is a solution in search of a problem. Lacking such, the problem had to be fabricated.

SQL has many problems that PRQL ostensibly addresses. Query reuse, composability, abstraction and more.

Query reuse, composability and abstraction are all sufficiently solved with views in my experience.

Re: Relational is more than SQL

#149

Post by ako » Sun, Sep 17, 2023, 4:10 PM UTC

anon84873628 wrote: post #135

ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

You might find Malloy interesting as it makes a greater departure from SQL syntax. Queries are first class objects which can be nested within each other in order to do trellising. It still compiles to SQL because that is the only language accepted by DBMSs today; however it will automatically write symmetric aggregate calculations and do those nestings that are hard for a human to write. https://www.malloydata.dev/

How are views not first class query objects?

Re: Relational is more than SQL

#150

Post by lolinder » Sun, Sep 17, 2023, 5:03 PM UTC

maximilianroos wrote: post #140

edgyquant wrote: post #139

Earlier quoted context omitted.

If you know then yes you know the shape of the data. You may not know the number of rows, but I fail to see how that makes it not analyzable.

Quoting from https://www.scattered-thoughts.net/writing/against-sql/ : --- There are many cases where a small change to a computation requires totally changing the structure of the query, but subqueries are my favourite because they're the most obvious way to express many queries and yet also provide so many cliffs to fall off. -- for each manager, find their employee with the highest salary > select > manager.name,…

Difficult for the author, but not for static analysis. A static analysis system can pretty easily enforce that `limit 1` be set when a query is used in that position.