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

ggsql: A Grammar of Graphics for SQL

opensource.posit.co

Post reply on HN
Print view View original

61–70 of 91 posts

Re: ggsql: A Grammar of Graphics for SQL

#61

Post by thomasp85 »

JHonaker wrote: post #59

I applaud the project, and I completely agree that the concepts maps nicely to SQL. The R equivalent of a WITH data prep block followed by the VISUALIZE is pretty much how all my plotting code is structured. However, I don't see what the benefits of this are (other than having a simple DSL, but that creates the yet another DSL problme) over ggplot2. What do I gain by using this over ggplot2 in R? The only problem, an…

We are not out to convince anyone to switch from ggplot2 (and we are not planning to stop developing that).

ggsql is (partly) about reaching new audiences and putting powerful visualisation in new places. If you live in R most of the time I wouldn't expect you to be the prime audience for this (though you may have fun exploring it since it contains some pretty interesting things ggplot2 doesn't have)

Re: ggsql: A Grammar of Graphics for SQL

#62

Post by i000 »

thomasp85 wrote: post #36
rvba wrote: post #32

1) does this alllw to export to Excel? 2) how to make manual adjustments?

My answers will probably disappoint 1) No (unless you count 'render to image and insert that into your excel document') 2) This is not possible - manual adjustments are not reproducible and we live by that ethos

What makes ggplot great is that it allows manual adjustments AND has a nice declerative grammar. Hard for me to see the value of a plotting library without being able to adjust plots.

Re: ggsql: A Grammar of Graphics for SQL

#63

Post by urams »

psadri wrote: post #55
urams wrote: post #51

What feels like a lifetime ago, I made almost all of the R tooling at Uber and actually implemented what was effectively exactly this on top of the R DB tooling. Everyone, I think correctly in retrospect, I showed it to thought it was more or less useless. I had hoped it would be a nice way to pull and instantly visualize data but that was rarely all that valuable like this.

What do you think is missing? I'm a big SQL fan and the idea of direct SQL to X seems appealing at least on the surface.

Probably the biggest issue is that it's primarily useful in the context of exploratory analysis and makes iteration on a plot much slower, requiring you to re-run the query to get a new viz. Iterating on a viz is best done with the data cached locally or elsewhere.

In the context of a query used for a dashboard in prod, you're likely using a different viz environment so it's not useful at all there.

Re: ggsql: A Grammar of Graphics for SQL

#64

Post by mbreese »

nchagnet wrote: post #29
getnormality wrote: post #19

I skimmed the article for an explanation of why this is needed, what problem it solves, and didn't find one I could follow. Is the point that we want to be able to ask for visualizations directly against tables in remote SQL databases, instead of having to first pull the data into R data frames so we can run ggplot on it? But why create a new SQL-like language? We already have a package, dbplyr, that translates betwe…

I was quite psyched when I read this so maybe I can tell you why it's interesting to me, although I agree the announcement could have done a better job at it. In my experience, the only thing data fields share is SQL (analysts, scientists and engineers). As you said, you could do the same in R, but your project may not be written in R, or Python, but it likely uses an SQL database and some engine to access the data.…

But isn't this then just another tool that you're including in your project? I don't get why I would want to add this as a visualization tool to a project, if it's already using R, or Python, etc...

I mean, is it to avoid loading the full data into a dataframe/table in memory?

I just don't see what the pain point this solves is. ggplot solves quite a lot of this already, so I don't doubt that the authors know the domain well. I just don't see the why this.

Re: ggsql: A Grammar of Graphics for SQL

#65

Post by oofbey »

getnormality wrote: post #19

I skimmed the article for an explanation of why this is needed, what problem it solves, and didn't find one I could follow. Is the point that we want to be able to ask for visualizations directly against tables in remote SQL databases, instead of having to first pull the data into R data frames so we can run ggplot on it? But why create a new SQL-like language? We already have a package, dbplyr, that translates betwe…

There’s certainly some benefit in a declarative language for creating charts from SQL. Obviously this doesn’t do anything that you can’t also do easily in R or Python / matplotlib using about the same number of lines of code. But safely sandboxing those against malicious input is difficult. Whereas with a declarative language like this you could host something where an untrusted user enters the ggsql and you give them the chart.

So it’s something. But for most uses just prompting your favorite LLM to generate the matplotlib code is much easier.

Re: ggsql: A Grammar of Graphics for SQL

#67

Post by levocardia »

nchagnet wrote: post #29
getnormality wrote: post #19

I skimmed the article for an explanation of why this is needed, what problem it solves, and didn't find one I could follow. Is the point that we want to be able to ask for visualizations directly against tables in remote SQL databases, instead of having to first pull the data into R data frames so we can run ggplot on it? But why create a new SQL-like language? We already have a package, dbplyr, that translates betwe…

I was quite psyched when I read this so maybe I can tell you why it's interesting to me, although I agree the announcement could have done a better job at it. In my experience, the only thing data fields share is SQL (analysts, scientists and engineers). As you said, you could do the same in R, but your project may not be written in R, or Python, but it likely uses an SQL database and some engine to access the data.…

I share your pain. You might enjoy Plotnine for python, helps ease the pain. The only bad thing about ggplot is that once you learn it you start to hate every other plotting system. Iteration is so fast, and it is so easy to go from scrappy EDA plot to publication-quality plotting, it just blows everything else out of the water.

Re: ggsql: A Grammar of Graphics for SQL

#69

Post by philipallstar »

tantalor wrote: post #27
anentropic wrote: post #9

Maybe I skim read it too fast, but I did not find any clear description in the blog post or website docs of how this relates to SQL databases I was kind of guessing that it doesn't run in a database, that it's a SQL-like syntax for a visualisation DSL handled by front end chart library. That appears to be what is described in https://ggsql.org/get_started/anatomy.html But then https://ggsql.org/faq.html has a section…

> SQL databases ... confused "SQL" and "databases" are different things SQL is a declarative language for data manipulation. You can use SQL to query a database, but there's nothing special about databases. You can also write SQL to query other non-database sources like flat files, data streams, or data in a program's memory. Conversely, you can query a database without SQL.

A SQL database is a database you can connect to and query with SQL.

Re: ggsql: A Grammar of Graphics for SQL

#70

Post by philipallstar »

mbreese wrote: post #64
nchagnet wrote: post #29

Earlier quoted context omitted.

I was quite psyched when I read this so maybe I can tell you why it's interesting to me, although I agree the announcement could have done a better job at it. In my experience, the only thing data fields share is SQL (analysts, scientists and engineers). As you said, you could do the same in R, but your project may not be written in R, or Python, but it likely uses an SQL database and some engine to access the data.…

But isn't this then just another tool that you're including in your project? I don't get why I would want to add this as a visualization tool to a project, if it's already using R, or Python, etc... I mean, is it to avoid loading the full data into a dataframe/table in memory? I just don't see what the pain point this solves is. ggplot solves quite a lot of this already, so I don't doubt that the authors know the dom…

Anything to standardise some of the horrifying crap that data scientists write to visualise something.
Post reply on HN