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

21–30 of 302 posts

Re: PRQL – A proposal for a better SQL

#21

Post by maximilianroos »

tfehring wrote: post #17

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

Thanks!

> Did you consider using a keyword like `let` for column declarations

Yeah, the current design for that is not nice. Good point re the keyword scanning. I actually listed `let` as an option in the notes section. Kusto uses `extend`; dplyr uses `mutate`; pandas uses `assign`.

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

Re: PRQL – A proposal for a better SQL

#22

Post by bob1029 »

omarhaneef wrote: post #12
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.

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 magical for me. When people don't understand the business or simply the game around how you talk about the business, things start getting messy wrt joins.

Re: PRQL – A proposal for a better SQL

#27

Post by dirslashls »

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.

Go to https://sqlframes.com/demo and in the code editor enter the following and execute (this example is taken from the first example on PRQL github page). It generates SQL, but it also computes and displays the results within the browser (though the data set below gives no results).

const employees = SQL.values([{ title: 'Developer', country: 'USA', salary: 120, payroll_tax: 20, healthcare_cost: 6 }]); employees.schemaName = 'employees'; const { groupBy, where: { gt, eq, and }, agg: { count, sum, avg } } = SQL; return employees.pdf(SQL.script('[salary]+[payroll_tax]').as('gross_salary'),SQL.script('[gross_salary]+[healthcare_cost]').as('gross_cost')) .fdf(and(gt('gross_cost',0),eq('country','USA'))) .gdf(groupBy('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('gross_cost').as('sum_gross_cost') ,count().as('count')) .having(gt('count',200)) .orderBy('sum_gross_cost');

Re: PRQL – A proposal for a better SQL

#28

Post by mongol »

I think it would be worthwhile to develop a shorthand of the same thing, suitable for use on the command prompt. Something using symbols as synonyms for keywords. Less eligble but more useful in a future when shell tools understand this syntax.

Re: PRQL – A proposal for a better SQL

#29

Post by badhombres »

jacktheturtle wrote: post #23

Do people still write SQL?

Absolutely. If I use a SQL db for my applications (I'm a software dev for context), I generally write raw SQL vs using an ORM. I find the long term issues of an ORM to not be worth investing and understanding SQL.

I'm also not having to learn a new library, in addition to the standard DB connection libraries, ~if~ when I switch a language or platform for some project.

Re: PRQL – A proposal for a better SQL

#30

Post by maximilianroos »

xi wrote: post #4
maximilianroos wrote: post #2

I wrote this over the holidays, because I find SQL wonderfully elegant in its function, but really frustrating in its form. Let me know any feedback — as you can see it's still at the proposal stage. If it gains some traction I'll write an implementation.

Maybe you'd like to check FunSQL.jl, my library for compositional construction of SQL queries. It also follows algebraic approach and covers many analytical features of SQL including aggregates/window functions, recursive queries and correlated subqueries/lateral joins. One thing where it differs from dlpyr and similar packages is how it separates aggregation from grouping (by modeling GROUP BY with a universal aggre…

This is awesome! I'll add a link to it on PRQL.

I guess the biggest difference between FunSQL (and similarly dbplyr) and PRQL is that the former needs a Julia (or R) runtime to run.

I really respect the library and keen to see how it develops.

Post reply on HN