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

191–200 of 302 posts

Re: PRQL – A proposal for a better SQL

#191

Post by 6gvONxR4sf7o »

maximilianroos wrote: post #55
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…

This is great feedback, and I agree with you re de-prioritizing terseness. And I agree with you on both the assignments and `split` being a bit awkward. Kusto just uses `by`, WDYT?

Group by seems good enough and not changing terms where there isn’t good reason seems like a good goal. Is PRQL’s split the same as SQL’s group by?

Re: PRQL – A proposal for a better SQL

#192

Post by RedCrowbar »

maximilianroos wrote: post #47
lijogdfljk wrote: post #43

I wonder how this compares in practice to EdgeQL, https://www.edgedb.com/showcase/edgeql Offhand i thought PRQL seemed easier to reason about, but something about EdgeQL seems better to me.. though i can't describe it.

I see EdgeQL as an excellent replacement for SQL in OLTP settings — it has great language integration and a unified relational & typing approach. (Please correct me if this is mistaken though). I wrote the PRQL proposal for analytical / OLAP queries, where the pipeline of transformations are more important, and relations and typing are relatively less important.

EdgeQL is getting support for generic partitioning/aggregating `GROUP` very soon [1], so we are giving some love to the analytical side of things too :-)

We definitely need more collective effort put into "Better SQL", so PRQL is a welcome sight!

[1] https://github.com/edgedb/rfcs/blob/21e581a188715c6ff82944b6...

Re: PRQL – A proposal for a better SQL

#193

Post by makeitdouble »

hn_throwaway_99 wrote: post #180
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…

> On the brief topic of form vs. flexibility. SQL is a thing that, when complex, is written by many people over the course of its lifetime - removing the ability to make bad decisions is better than enabling the ability to write simple things even simpler Hallelujah! But, to your footnote, this is a major reason why I despise ORMs. In my mind they make writing simple code slightly easier, but they make complicated SQ…

On ORMs, the best use I see of them is for “transparent” queries that you don’t define.

Like fetching a record by id, or a single record and all of its related properties. Or a list of all the record in a table matching a simple filter.

That’s 98% of what we do against the DB, and I’m all for having it basically invisible.

Then let’s just bypass the ORM altogether the minute we think about joining or grouping things together. There are libs in most language that help just sanitize queries, so it’s no difficult really.

Re: PRQL – A proposal for a better SQL

#195

Post by maximilianroos »

justinpombrio wrote: post #186
maximilianroos wrote: post #76

Earlier quoted context omitted.

I've added the `let` keyword given a few people commented on this.

Awesome that you're responding to feedback like this! Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`. Those are in effect pretty different operations: you need to know which one is happening to know how many columns the table will have, and renaming a table column can with your current system change w…

Yes this is a good idea. dplyr has something similar with `mutate` & `transmute`.

This could _mostly_ be enforced by PRQL. There's a case where we transpile to:

  select *, x+1 as x_plus_one
...where we don't know whether or not we're overwriting an existing column. But it's a minority of cases, and the contract could stand within PRQL.

I opened an issue here: https://github.com/max-sixty/prql/issues/6

Re: PRQL – A proposal for a better SQL

#196

Post by political12345 »

Why not use R's data.table? You can achieve literally the same pipeline style flow, internally it's written in C, it's not the fastest but gets the job done.

If you want real speed but no external package, kdb/q is probably better (has q-sql).

Good work for the effort etc. but I often don't see the value added of these toy projects of people apart from personal development and a bullet point on the CV of the author.

Re: PRQL – A proposal for a better SQL

#197

Post by cerved »

aloisdg wrote: post #163
hackeredje wrote: post #33

Is this not Linq ? https://stackoverflow.com/questions/tagged/linq ? And then dump the queries via https://stackoverflow.com/questions/1412863/how-do-i-view-th... or https://www.linqpad.net/ ?

Indeed. It looks a lot like dotnet's Linq.

wr to linq to sql: the difference is linq works by making objects to tables and dotnet primitives to sql types, often producing really poor queries as a result

Re: PRQL – A proposal for a better SQL

#198

Post by twoodfin »

correct-me-plz wrote: post #94
ako wrote: post #86

Earlier quoted context omitted.

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…

Snowflake lets you refer to column aliases, and it's great! There's the slight issue of shadowing of table column names, which they resolve by preferring columns to aliases if both are named the same. So sometimes my aliases end up prefixed with underscores, but that's not a big deal.

The trade-off is that a schema change (adding a column) unrelated to your query can modify its behavior.

Favoring aliases over columns instead has the potential to introduce irresolvable ambiguities as you can’t “qualify” a column alias with a SELECT list or subquery ID the way you can qualify a column by its table/view alias.

Re: PRQL – A proposal for a better SQL

#199

Post by eurasiantiger »

bob1029 wrote: post #22
omarhaneef wrote: post #12

Earlier quoted context omitted.

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.

There is no such thing as a domain-agnostic SQL database that holds up under this kind of semantic scrutiny. I don't think that there ever could be. If you are rolling a SQL schema for a home improvement contractor, it is extraordinarily unlikely that their specific business would expect any scenarios in which carpets are sometimes known as furniture. Having a bounded context to operate within is what makes SQL magic…

EdgeDB

Re: PRQL – A proposal for a better SQL

#200

Post by tester756 »

louthy wrote: post #174
tester756 wrote: post #143

Earlier quoted context omitted.

Funnily enough LINQ Query syntax is really uncommon and everybody uses method syntax var list = new List {1,2,3} var extracted = list ....................Where(x => x > 1) ....................Select(x => $"my number: {x}) ....................ToList();

> everybody Not everybody

99%? 98%?
Post reply on HN