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

131–140 of 302 posts

Re: PRQL – A proposal for a better SQL

#131

Post by maximilianroos »

ianbicking wrote: post #78

I like it, it's readable, unlike some SQL alternatives I've seen it doesn't make me feel like I'm dumb and don't understand what a query even is. I can't decide if it would be better or worse if it stuck more closely to SQL keywords. You use "from" and "select", but not "where", "order by", "group by". There's some danger of it being in an uncanny valley of SQLish, but I'm pretty sure I'd prefer just using those term…

Thanks!

I just fleshed out composing CTEs, which is a small step towards the broader goal of making composition easier: https://github.com/max-sixty/prql/commit/dc68fcaaceef26cc078...

Let me know if you have a good case of the sort of composition you find difficult in SQL (either here or in an issue). Thank you!

Re: PRQL – A proposal for a better SQL

#132

Post by gmfawcett »

ako wrote: post #86
magicalhippo wrote: post #62

Now this is actually nice, unlike the other suggestion posted today[1]. Maybe I'm just too used to non-standard extensions of our database but the SQL example could, at least for our db, be rewritten as SELECT TOP 20 title, country, AVG(salary) AS average_salary, SUM(salary) AS sum_salary, AVG(gross_salary) AS average_gross_salary, SUM(gross_salary) AS sum_gross_salary, AVG(gross_cost) AS average_gross_cost, SUM(gros…

With a CTE it would read a bit more like prql: with usa_employees as ( SELECT title, country, salary, (salary + payroll_tax) AS gross_salary, (salary + payroll_tax + healthcare_cost) AS gross_cost FROM employees WHERE country = 'USA' AND (salary + payroll_tax + healthcare_cost) > 0 ) select title, country, AVG(salary) AS average_salary, SUM(salary) AS sum_salary, AVG(gross_salary) AS average_gross_salary, SUM(gross_s…

Not all database systems can optimize queries well over CTE boundaries. I believe this is still true for PostgreSQL (no longer true, see below -- it was true a few years ago). So there's a potential performance hit for (the otherwise excellent advice of) writing with CTE's.

Re: PRQL – A proposal for a better SQL

#133

Post by jnsie »

munk-a wrote: post #48

I like the flow direction compared to standard SQL. SQL is supposed to read like a sentence I suppose but I have many times looked at it and really wanted things to be in a more logical order. My main suggestion would be to be a bit less terse and introduce a bit more firm formatting. I'm not a huge fan of the term "split" and feel like jazzing that up to "split over" or even just reviving "group by" would improve re…

I like the flow direction specifically for intellisense/autocomplete. I'm sure it would be easier to provide hints when the table name is known immediately.

Re: PRQL – A proposal for a better SQL

#134

Post by thanatos519 »

haolez wrote: post #19

This actually looks like an improvement (and I like SQL). This feels closer to non-programmers, contrary to some other SQL "competitors" like that query language from InfluxDB.

It definitely scans better than 'Flux' from InfluxDB2.

One thing I like about Flux is the ability to split streams and return multiple distinct aggregations. Very handy in Grafana dashboards!

Re: PRQL – A proposal for a better SQL

#136

Post by dgudkov »

>PRQL is intended to be a modern, simple, declarative language for transforming data

It's not declarative. It's functional.

I believe that the approach that is followed by PRQL is more practical than SQL. We've implemented a similar approach in our visual ETL tool for non-technical people (https://easymorph.com) and it works wonderfully. Other cool things you can do with this approach (and can't with SQL):

* Modify existing columns without re-selecting the whole dataset

* Loops (iterations)

* Conditional IF/THEN/ELSE branching as a workflow statement

* Exceptions & error handling

Re: PRQL – A proposal for a better SQL

#137

Post by tester756 »

_jal wrote: post #128
phailhaus wrote: post #112

Earlier quoted context omitted.

Building for autocomplete is building for human understanding. If it is impossible for a computer to determine the context of your query, why would a human do much better?

They are not fully-aligned goals, and autocomplete should not be given equal consideration on par with human clarity. If you want nice autocomplete too, that's fine, but if there is a tradeoff, human understanding is the primary concern.

I don't understand why do you think about it this way

C#'s LINQ (really powerful tool similar to SQL) works the same way

look:

var list = new List{1,2,3}

var extracted = list

.............................Where(x => x > 1)

.............................Select(x => $"my number: {x})

.............................ToList();

or

var extarcted =

........................from x in list

........................where x > 1

........................select $"my number: {x};

Re: PRQL – A proposal for a better SQL

#138

Post by topspin »

ajkjk wrote: post #105
ajkjk wrote: post #101

Just wanna say, I absolutely love this.

One piece of feedback: "sort sum_gross_cost # Uses the auto-generated column name." ... seems like a huge landmine. Languages really should not have any implicit way of constructing identifiers (among other reasons it is not easily greppable). You might consider using a syntax like `sum:gross_cost` which can function as a sort parameter and an aggregation, but is actually recognizable as an object instead of having a…

> # Uses the auto-generated column name

The fact that someone felt the need to add that comment hints at a design mistake. Synthesizing symbols is weird, unnecessary and is probably a violation of the principle of least surprise.

Otherwise I think PRQL has some value. Nice work. I strongly suspect that if SQL looked more like this there would be a lot more people willing to use the query language directly and perhaps fewer that are compelled to bury it under shifting layers of fragile abstractions.

Re: PRQL – A proposal for a better SQL

#139

Post by ridaj »

maximilianroos wrote: post #82
ridaj wrote: post #77

Very cool Design goal question - is the goal to have a language that blindly compiles to SQL, or will compilation require data schema knowledge? Suggestion: where possible stick to the well established SQL keywords (prefer "group by" to "aggregate by")

Initially the transpiling would be context-free of the schema. It would really nice to have context when _writing_ the code, so we could do things like autocomplete (IIUC this is what Malloy does already). Are there features you can think of that would be helpful if we had the schema context during transpiling?

I wasn't thinking it'd be useful, but more that it's good to remain as free as possible from any assumptions about the schema of the data. I often work with tables that have unusually large schemas (> 100MB) and have seen some products' performance severely degrade as a function of schema complexity.

(But otherwise +1 to schema awareness during authoring.)

Post reply on HN