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

131–140 of 177 posts

Re: Relational is more than SQL

#131

Post by maximilianroos »

dragonwriter wrote: post #123
maximilianroos wrote: post #113

Earlier quoted context omitted.

[PRQL dev here] I strongly think we should have the best examples of SQL to compare against. I've ironically made this complaint for other libraries, so I'm alarmed that folks think we might have done the same. We would take a PR for the first example if folks think that's better spacing. (I think the spacing is the only difference?) For the second — `USING` isn't fully equivalent to `ON`. There are discussions on GH…

> For the second — `USING` isn’t fully equivalent to `ON`. In terms of portability because its not supported by, e.g., MSSQL, sure. In terms of its semantics, though: t1 [LEFT/RIGHT/INNER] JOIN t2 USING col Is fully equivalent to: t1 [LEFT/RIGHT/INNER] JOIN t2 ON (t1.col == t2.col) So for a comparison to SQL as used by most RDBMSs (rather than MSSQL specifically), rather than “what should PRQL compile to”, USING is q…

I posted a link to the issue discussing this on the repo. That gives a good overview to those interested in this issue.

To take one point from there:

> Is fully equivalent to:

They're not fully equivalent — `USING` combines the two columns into a single column, `ON` doesn't.

Re: Relational is more than SQL

#132

Post by maximilianroos »

lolinder wrote: post #126
maximilianroos wrote: post #113

Earlier quoted context omitted.

[PRQL dev here] I strongly think we should have the best examples of SQL to compare against. I've ironically made this complaint for other libraries, so I'm alarmed that folks think we might have done the same. We would take a PR for the first example if folks think that's better spacing. (I think the spacing is the only difference?) For the second — `USING` isn't fully equivalent to `ON`. There are discussions on GH…

> 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...)

Re: Relational is more than SQL

#133

Post by maximilianroos »

ttfkam wrote: post #124
maximilianroos wrote: post #118

Earlier quoted context omitted.

So I agree that unperformant SQL is unperformant, but PRQL can _reduce_ the chance of making mistakes there. Here's an example [1] of someone reporting that a query engine was far more performant with one SQL construction, and then PRQL changing the SQL we output to use that construction. GCC & Clang are much better at compiling to assembly than any person! PRQL isn't there yet, but each improvement scales to everyon…

Be honest. C to object code to linker to final binary are a MUCH bigger leap than PRQL to SQL. You make it sound like SQL is some insurmountable hurdle while PRQL is a bunny slope. You're not getting anywhere with that nonsense. [Disclaimer: not a PRQL dev]

I don't know where this aggression is coming from — we're an open-source project, only volunteers, trying to do something that makes it easier for folks to work with data.

Critical & constructive feedback would be really appreciated, but that's not this — why all the snark?

Re: Relational is more than SQL

#134

Post by maximilianroos »

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…

Again — we agree — with omniscience, it's possible to statically analyze everything. My claim is some languages can be statically analyzed with much less context than others.

Check out "Expression substitution" at https://www.scattered-thoughts.net/writing/against-sql/ if you're interested in more here.

Re: Relational is more than SQL

#135

Post by anon84873628 »

ttfkam wrote: post #68
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…

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/

Re: Relational is more than SQL

#136

Post by anon84873628 »

lolinder wrote: post #98
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 will never die for the same reason that JavaScript will never die: because it's built in to all major database engines. In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple se…

Well, Malloy is developed within Google by the founder of Looker, so there is a chance it could be natively integrated into BigQuery. At that point you have a next gen SQL replacement available on one of the most widely used analytics and transformation engines.

Re: Relational is more than SQL

#137

Post by anon84873628 »

ledauphin wrote: post #67
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…

I've been excited in the abstract about PRQL for quite a while. But something FQL seems to have a much better handle on is the value of document-orientedness, or what you might alternatively call "gradual schematization". This problem has been solved (if not beautifully, at least acceptably) by modern SQL databases that support a JSON storage format and associated "secondary query language". I know PRQL has had an op…

FQL is interesting because it focuses on transactional systems and eliminating the need for an ORM in applications. I feel many of the SQL replacement projects like PRQL and Malloy instead come from the analytics side of the house, which doesn't really help application developers at all. (But does raise the question, how do I do analytics in Fauna? Do I ETL to a traditional warehouse system?)

Re: Relational is more than SQL

#138

Post by anon84873628 »

iamcreasy wrote: post #32
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 would you compare prql with dbt?

dbt is just an orchestration tool. It uses SQL because that's what you need to pass to the target database. There is a python plugin if you prefer to use that for your models instead. Theoretically dbt could wrap any language your target system accepts. The actual configuration of the dbt runtime itself is done with yaml files.

Re: Relational is more than SQL

#139

Post by edgyquant »

maximilianroos wrote: post #117
lolinder wrote: post #98

Earlier quoted context omitted.

SQL will never die for the same reason that JavaScript will never die: because it's built in to all major database engines. In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple se…

[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…

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.

Re: Relational is more than SQL

#140

Post by maximilianroos »

edgyquant wrote: post #139
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…

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,
    >   (select employee.name
    >    from employee
    >    where employee.manager = manager.name
    >    order by employee.salary desc
    >    limit 1)
    > from manager;
     name  | name
    -------+------
     alice | bob
---

If the inner query has more than one row, the query will raise an error. That's difficult to know from the SQL alone.

Post reply on HN