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

121–130 of 177 posts

Re: Relational is more than SQL

#121

Post by lolinder »

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…

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 that `SELECT sum(foo)` will always return one row with one column that is an integer type, while `SELECT foo, bar` returns some number of rows that have foo and bar columns whose types can be inferred from the CREATE TABLE statements.

Re: Relational is more than SQL

#122

Post by scott_meyer »

slotrans wrote: post #86

Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.

what is a document? How is an ORANUM or a bignum not a document?

One motivation for creating documents is that modeling document contents as relations requires the creation of a bunch of primary keys which no natural definition. A simple document might be an ordered collection of paragraphs, [p23, p57, ...]

Modifying such things is difficult. In fact, the most effective way of structuring modification seems to be OTs based on document offsets. What Google docs does.

Re: Relational is more than SQL

#123

Post by dragonwriter »

maximilianroos wrote: post #113
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 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 quite appropriate.

It may be that the intent of the homepage pairing is to highlight the actual compilation result and not provide a comparison to SQL-as-it-would-manually-be-written, but the presentation doesn’t make it clear that that’s the purpose.

Re: Relational is more than SQL

#124

Post by ttfkam »

maximilianroos wrote: post #118
lolinder wrote: post #101

Earlier quoted context omitted.

It does make a difference if the resulting SQL is unperformant. Someone who is good at SQL can look at a query and see where the query planner might go wrong, then make subtle tweaks to get better performance. Optimizing queries in a compile-to-SQL language basically has to be left to the compiler, which may not have the context needed to write performant SQL. Compiling a query is different than compiling a whole pro…

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]

Re: Relational is more than SQL

#125

Post by ttfkam »

lolinder wrote: post #101
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.

It does make a difference if the resulting SQL is unperformant. Someone who is good at SQL can look at a query and see where the query planner might go wrong, then make subtle tweaks to get better performance. Optimizing queries in a compile-to-SQL language basically has to be left to the compiler, which may not have the context needed to write performant SQL. Compiling a query is different than compiling a whole pro…

Agreed.

Also, someone who ISN'T good at SQL can look at EXPLAIN output and see where the query planner HAS gone wrong.

Adding PRQL to the mix unambiguously makes that analysis and optimization step harder.

Re: Relational is more than SQL

#126

Post by lolinder »

maximilianroos wrote: post #113
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 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.

Re: Relational is more than SQL

#127

Post by dragonwriter »

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…

> As a really basic example: `SELECT FROM tbl` — can we tell what shape the result is?

Like most statically analyzable code, you have problems if you try to statically analyze part of the code without the relevant definitions.

But, yes, if you have the relevant code (e.g., the DDL for the table), you can. (Without it, you can in the sense that you can statically determine it as a function of the table definition, which can be sufficient in some cases.)

> in SQL, shapes / types require a lot of context — the result could be a single row in the case of `SUM(foo)`, or it could be every row in the case of `foo, bar`.

Oh, you mean, can we statically determine the shape of an expression’s results without knowing the expression? Well, no, and that’s true in most statically-analyzable languages.

Re: Relational is more than SQL

#128

Post by [deleted] »

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…

[deleted]

Re: Relational is more than SQL

#129

Post by [deleted] »

slotrans wrote: post #86

Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.

[deleted]

Re: Relational is more than SQL

#130

Post by deburo »

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 looks awesome. Does it support directly querying against databases (PostgreSQL, SQL Server, ...)? ie. is there a "Run" command in vscode that takes care of compiling & running the compiled sql?
Post reply on HN