Obligatory reading
https://www.scattered-thoughts.net/writing/against-sql/
PRQL – A proposal for a better SQL
71–80 of 302 posts
Re: PRQL – A proposal for a better SQL
#72I've always wondered why there aren't query languages that embrace algebraic data types and pattern matching. Seems like an obvious fit to me. There's many times where you'd want to model a table that has either this scheme or that schema.
They can work well. In the project I'm working on the database uses algebraic datatype keys (i.e. tags and tag-dependent columns) to make the database faster and smaller than an equivalent relational schema, but the database is used via API rather than via a query language.
Re: PRQL – A proposal for a better SQL
#73We barely learned SQL for all these years and the guy wants to change it now. Thank you but no thank you.
JK. Cool concept and hopefully it catches.
Re: PRQL – A proposal for a better SQL
#74I've always wondered why there aren't query languages that embrace algebraic data types and pattern matching. Seems like an obvious fit to me. There's many times where you'd want to model a table that has either this scheme or that schema.
Check out C# and LINQ. They pull it off with anonymous types.
Re: PRQL – A proposal for a better SQL
#75Any chance of starting with FROM perhaps to help with autocomplete? From Table or FROMT TABLEA JOIN TABLE B ... The autocomplete would then be able to introspect much better in the tooling side.
Queries start with FROM, it's called a README for a reason...
Re: PRQL – A proposal for a better SQL
#76Very 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
I've added the `let` keyword given a few people commented on this.
Re: PRQL – A proposal for a better SQL
#77Very 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")
Re: PRQL – A proposal for a better SQL
#78I 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 terms verbatim (including the space in "order by"... that style is less common in modern languages but it's not really that much harder to parse).
I'd like to see more examples of joins and composing SQL. Does this language make it easier to make more general SQL queries? Can I take two queries and squash them together in a reliable way? I feel like I end up with a lot of theme and variation in my queries, often involving optional filters.
I might even like a notion of encapsulation that could help this query language when it's embedded in other languages. Like if I could say, in the language itself, that a query has certain unbound variables (and not just ? or other placeholders). This language seems like it would be better for generating than SQL, and sometimes generation is just necessary (like in any application that supports data exploration), but for most common cases I'd hope to avoid that. Defining inputs and then making whole filter sections or other statements conditional on those inputs would help here.
Re: PRQL – A proposal for a better SQL
#79I 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?
Yes Kusto's `by` is excellent!
Re: PRQL – A proposal for a better SQL
#80This seems very similar to Kusto/KQL.