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

PRQL – A proposal for a better SQL

github.com

Post reply on HN
Print view View original

11–20 of 302 posts

Re: PRQL – A proposal for a better SQL

#11

Post by pmontra »

First, kudos because it takes courage to take on SQL in this way.

Second, this kind of reversed SQL (filter-first, select-last) is much easier to reason about than the original and keep in mind that I prefer to code complex queries in SQL than to build or translate them in the ORM of the project I'm working on.

Maybe a transpiler is an inevitable first step but I think that any SQL replacement should be itself the target of ORMs and run directly in the database CLI tools (psql / mysql ...) or IDEs (pgAdmin, MySQLAdmin, ...). What's the long term plan of the project?

Re: PRQL – A proposal for a better SQL

#12

Post by omarhaneef »

bachmeier wrote: post #5

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.

Re: PRQL – A proposal for a better SQL

#14

Post by nassimsoftware »

eatonphil wrote: post #10
nassimsoftware wrote: post #8

It would be definitely interesting to have a TypeScript of some sort but for SQL. So a more practical and prettier syntaxe like what I'm seeing here that compiles to SQL queries.

TypeScript is more verbose than JavaScript. While I love to use TypeScript I don't think I'd categorize it as prettier than JavaScript. And practical... well if you mean it is more maintainable then yes but if you mean faster to write then no. I don't want a more verbose SQL I want a less verbose SQL!

I meant more the aspect that with TypeScript people would prefer to write in it and then compile to JavaScript because there is a benefit. With a PRQL with an SQL compilation target we would reap the benefit of a more practical and better syntax. In both cases they bring benefits but not in the same way.

Re: PRQL – A proposal for a better SQL

#16

Post by maximilianroos »

pmontra wrote: post #11

First, kudos because it takes courage to take on SQL in this way. Second, this kind of reversed SQL (filter-first, select-last) is much easier to reason about than the original and keep in mind that I prefer to code complex queries in SQL than to build or translate them in the ORM of the project I'm working on. Maybe a transpiler is an inevitable first step but I think that any SQL replacement should be itself the ta…

Thanks!

I agree that integrating with the DB would allow much more from a lang. But PRQL is a bet that languages which start there (e.g Kusto) get lost because it requires changing DB, which is really hard. I worry EdgeDB may hit this issue too (but I'm really hoping it works, and they have an excellent team).

As I think you're suggesting — you could imagine a language starting out as a transpiler, and then over time DBs working with it directly, cutting out some of the impediment mismatch.

Malloy [1] is another point in space — it targets existing DBs through SQL queries but can also ask for schemas etc while developing.

[1] https://github.com/looker-open-source/malloy

Re: PRQL – A proposal for a better SQL

#17

Post by tfehring »

Very cool! A couple questions/suggestions off the top of my head:

1. Did you consider using a keyword like `let` for column declarations, e.g. `let gross_salary = salary + payroll_tax` instead of just `gross_salary = salary + payroll_tax`? It's nice to be able to scan for keywords along the left side of the window, even if it's a bit more verbose.

2. How does it handle the pattern where you create two moderately complex CTEs or subqueries (maybe aggregated to different levels of granularity) and then join them to each other? I always found that pattern awkward to deal with in dplyr - you have to either assign one of the "subquery" results to a separate dataframe or parenthesize that logic in the middle of a bigger pipeline. Maybe table-returning functions would be a clean way to handle this?

Re: PRQL – A proposal for a better SQL

#18

Post by gibsonf1 »

SPARQL. Representing human information in relational tables goes against how people actually think and use information. We humans think in tremendous numbers of nested hierarchies, and recursive hierarchy traversal is a nightmare in relational databases. A graph is the structure for data that works best, is most efficient, and actually reflects how things are connected in our brains.
Post reply on HN