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

PRQL: Pipelined Relational Query Language

github.com

Post reply on HN
Print view View original

161–170 of 214 posts

Re: PRQL: Pipelined Relational Query Language

#161

Post by mulmen »

spullara wrote: post #154
mulmen wrote: post #146

Earlier quoted context omitted.

I don’t understand how changing the order of the clauses makes a query easier to type.

If you have auto-complete it can see what table you are using and complete the column names. Starting with SELECT it could be any column in the database.

Huh. I have been doing this for like 15 years and never have a problem. Text editors like Sublime Text suggest names based on the content of the file. SQL Developer, SQLWorkbench, and DataGrip all seem to handle it just fine.

Re: PRQL: Pipelined Relational Query Language

#162

Post by mikea1 »

hn_throwaway_99 wrote: post #112
OJFord wrote: post #74

Earlier quoted context omitted.

To me it seems quite nice, but really just trivially different from SQL - like if Ruby was 'friendlier syntax that transpiles to Python', meh? You'd use whichever you happened to learn first and not bother with the other. (That's often true even though it's more than that of course.) The examples arbitrarily make SQL look more verbose: SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 Yes! Of course I'd…

I agree that I think the difficulty with the uptake will be "it's really just less annoying SQL", and it's hard to overtake a technology that's so ubiquitous when your fixes are really "nice to haves" vs something truly transformational. That said, it's not the succinctness that's an improvement, it's that the pipelined nature of PRQL really maps much better to how people should think about queries, and also how the…

> the pipelined nature of PRQL really maps much better to how people should think about queries

I disagree. Database engines take SQL and transform it into an execution plan that takes into consideration database metadata (size, storage, index analytics, etc.). Queries should be thought of with a _set based_ instead of _procedural_ approach to maximize the benefits of this abstraction - diving into the implementation details to guide the execution plan formation only when necessary.

Also, the pipeline approach could be achieved with common table expressions (CTEs), right?

That said, I think PRQL looks promising because it is a solid attempt to make RDBMS development more approachable. I also like that `from` comes before `select`: it is far more readable. A solid and modern IDE experience for PRQL could be a "killer app".

Re: PRQL: Pipelined Relational Query Language

#163

Post by spullara »

nhinck2 wrote: post #157
spullara wrote: post #154

Earlier quoted context omitted.

If you have auto-complete it can see what table you are using and complete the column names. Starting with SELECT it could be any column in the database.

I see this complaint stated over and over again, how hard is it really to type SELECT * FROM x a and then go back?

Is there any downside at all to putting FROM first?

Re: PRQL: Pipelined Relational Query Language

#164

Post by [deleted] »

t8sr wrote: post #16
andrewl-hn wrote: post #6

For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…

I don't get that - to me the examples are much less readable than SQL and I don't understand why I should want to use this. Like, yes, you can reorder the query sections, which seems to be everyone's complaint about SQL, but then you also have multiple types of brackets, colons and other syntax for no reason, all while not really accomplishing anything SQL doesn't already do. What's the attraction?

[deleted]

Re: PRQL: Pipelined Relational Query Language

#165

Post by wodenokoto »

mikea1 wrote: post #162
hn_throwaway_99 wrote: post #112

Earlier quoted context omitted.

I agree that I think the difficulty with the uptake will be "it's really just less annoying SQL", and it's hard to overtake a technology that's so ubiquitous when your fixes are really "nice to haves" vs something truly transformational. That said, it's not the succinctness that's an improvement, it's that the pipelined nature of PRQL really maps much better to how people should think about queries, and also how the…

> the pipelined nature of PRQL really maps much better to how people should think about queries I disagree. Database engines take SQL and transform it into an execution plan that takes into consideration database metadata (size, storage, index analytics, etc.). Queries should be thought of with a _set based_ instead of _procedural_ approach to maximize the benefits of this abstraction - diving into the implementation…

I disagree. I find it extremely hard to reason about large queries as set transformations, whereas it is much easier to break it down to "first this, then that". And this is long before I've even started writing my first line of SQL.

So let me write it procedurally and have the optimization engine fix it for me, just like how it fixes my SQL.

Even SQL queries are often better understood procedurally. Take this one [1]:

    SELECT article, dealer, price
    FROM   shop s1
    WHERE  price=(SELECT MAX(s2.price)
                  FROM shop s2
                  WHERE s1.article = s2.article)
    ORDER BY article;
That inner WHERE clause doesn't make sense in my opinion, unless you think of it procedurally as for each row in s1, ask do a search for the highest price amongst all items that share article number.

[1] https://dev.mysql.com/doc/refman/8.0/en/example-maximum-colu...

Re: PRQL: Pipelined Relational Query Language

#166

Post by strken »

BrentOzar wrote: post #158
10000truths wrote: post #147

Earlier quoted context omitted.

I don't see why PRQL can't support data mutation. Just have an insert/update/delete operator that must go at the end of a pipeline, and which takes a table name as an argument. An SQL query like this: UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' Could then be written in PRQL as something like this: from counters filter startswith(name, 'prefix.') derive { new_value = value + 1 } select { name, new…

This feels way less intuitive than SQL: UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%'

I really hate that SQL doesn't let you do

   UPDATE counters WHERE name LIKE 'prefix.%' SET value = value + 1
In a SELECT it's fine, but in a mutation it's dangerous to make updating literally everything so easy if you leave off the tail.

Re: PRQL: Pipelined Relational Query Language

#167

Post by viraptor »

OJFord wrote: post #74
andrewl-hn wrote: post #6

For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…

To me it seems quite nice, but really just trivially different from SQL - like if Ruby was 'friendlier syntax that transpiles to Python', meh? You'd use whichever you happened to learn first and not bother with the other. (That's often true even though it's more than that of course.) The examples arbitrarily make SQL look more verbose: SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 Yes! Of course I'd…

It's not the tiny changes in the syntax/order that matter here. It's that if you want to limit the columns or do something else with them afterwards, in PRQL you append that text to the end. In SQL you'd have to wrap it around your original query, it inject joins in the middle. It doesn't read well anymore, because "how" you're doing things eclipses "what" you're doing.

For a simple select, this just doesn't matter. But you also wouldn't bother with PRQL for simple selects.

Re: PRQL: Pipelined Relational Query Language

#168

Post by robbywashere_ » 

    BlaBla.io Better Tomorrow Today(tm)

    Fullstack Engineer (React, Typescript, PRQL) (100% Remote)

    What We're Looking For:

    You’ve got 5+ years of experience in designing, building and maintaining large apps written in React, Typescript and PRQL

    ...
I'll just add it to my experience just to be safe

Re: PRQL: Pipelined Relational Query Language

#169

Post by mcsoft »

PRQL is a breath of fresh air. Reporting languages generally miss built-in visualization and drill-down capabilities. Ideal reporting query should define not only how to seek, join, and and aggregate data, but also how to visualize output and how to present details in reaction to user clicks. There are some limited efforts like in PowerBI and Splunk but we need a standard. I wonder if PRQL guys will address this need in the future.

Re: PRQL: Pipelined Relational Query Language

#170

Post by tgulacsi »

wodenokoto wrote: post #165
mikea1 wrote: post #162

Earlier quoted context omitted.

> the pipelined nature of PRQL really maps much better to how people should think about queries I disagree. Database engines take SQL and transform it into an execution plan that takes into consideration database metadata (size, storage, index analytics, etc.). Queries should be thought of with a _set based_ instead of _procedural_ approach to maximize the benefits of this abstraction - diving into the implementation…

I disagree. I find it extremely hard to reason about large queries as set transformations, whereas it is much easier to break it down to "first this, then that". And this is long before I've even started writing my first line of SQL. So let me write it procedurally and have the optimization engine fix it for me, just like how it fixes my SQL. Even SQL queries are often better understood procedurally. Take this one [1…

This is the "set based" approach for the MAX: there does not exist a bigger element:

  SELECT article, dealer, price
    FROM   shop s1
    WHERE  NOT EXISTS (SELECT 1 FROM shop s2 
                         WHERE s2.price > s1.price AND
                               s2.article = s2.article)
    ORDER BY article;
Post reply on HN