<https://chartio.com/blog/why-we-made-sql-visual-a...
# thinking-together
i
I could have sworn I've seen this before. Mariano, I'm curious to hear what you think of this, given you're working on a vaguely similar thing.
The UI for building queries looks pretty nice to me. I'd love to see something like this integrated with https://charticulator.com
m
it surprises me for sql that it tool so long, being a declarative language, pretty limited amount of syntax composition and how well defined the data on it is, still it's a good sign that people are going over the last 15 years of reinventing the olap cube ui
you may have seen ultorg https://vimeo.com/372006027
the ui of metabase is really cool too: https://www.metabase.com/
👍 1
the problem when you are so sql centric is that everything has to fit that model, which is ok, but many things don't, so you push the coplexity to the ETL process of getting the data to an sql database so you can do the easy part
s
oh man, I’ve dreamed of a visual SQL tool for many years now. Chartio used to have one but it wasn’t that great (this looks like a revamped one)
part of the challenge I still see with this approach laid on this blog post is it doesn’t focus enough on the actual workflow of SQL users (I’ve been a daily SQL user for 4+ years)
this seems to focus on making the act of writing SQL code more visual, with drag & drop but the process doesn’t tap into and complement the visual model a SQL user actually has
when I (and my team members) are writing SQL queries, we usually: • Start with a vague idea of what we need to query and do some select *’s + reading column names to identify relevant tables & columns. Pain point: I can’t quickly visualize the “table-space” of the database. Imagine a bunch of linked spreadsheets in a spatially oriented way to highlight the relationships between tables. • Start building up the query, run, iterate, add some joins. Pain point: no SQL tool encourages prototyping and iteration in a more data-oriented way. They all make you throw away the query you wrote and ran and the results table every time • At this point, I usually understand the “final form” of my query. What I want the table of results to actually look like, and then I have to work backwards and figure out the intermediate joins to get there. Pain Point: I do this on pencil & paper or in a vector drawing tool, but ideally this is somewhat augmented by the latent knowledge in the database tables. • Finally, I iterate on my long-ass SQL query until it feels right. Pain point: iteration is kinda painful, both the speed but also the fact that results are thrown away each time you run a query. Its hard to feel a sense of partial progress.
👍🏽 1
🍰 1
s
Oh boy this top comment nails it - https://news.ycombinator.com/item?id=22550217
m

https://www.youtube.com/watch?v=YBXMTipHGfQâ–ľ