Live data from Hacker News

I don't need your query language

antonz.org

41–50 of 304 posts

Re: I don't need your query language

#41
post #16

Earlier quoted context omitted.

Always start with the end in mind, first what your goal is then how to achieve it. Also, i don't actually see the problem because you never write a query in a lineair way. Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. By now, code completion works as the table is known. Wouldn't help much to write it table first.

Exactly, you could actually drop the `select` in this case and just say `from table limit 10` don't state what you don't need. What you describe is learned behavior to get along with a design flaw. SQL won't change, so no reason to worry. My point is: People keep creating new versions of it, because it is not as `easy` to work with as it could be.

That's valid DuckDB syntax

Re: I don't need your query language

#42
I felt the same way when Malloy[0] launched. It has some interesting features, but I couldn't see myself ever using it. Nothing makes a big enough difference to spend the time to learn it.

Would love to hear from anybody that's using it regularly

0 - https://www.malloydata.dev/

Re: I don't need your query language

#43

SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…

This is no longer true in database that have JSON support (which is most of them these days). You can aggregate the result of a subselect into a single column (the underling data doesn’t have to be stored as JSON, you can convert as part of the query)

Re: I don't need your query language

#44
The biggest advantage of SQL is that it's so common that if you deal with data a lot you tend to know it well enough. Sure, there are small differences between databases but joins/grouping/window functions tend to work similarly enough.

On the other hand, when I have to do a somewhat complex query in Elasticsearch, or MongoDB, or gorm, or Django ORM, I have to check each time in the docs how it's done.

Re: I don't need your query language

#45
post #37

SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…

Isn't your comment judging a fish by its ability to climb a tree?

If the task is to climb a tree, it's reasonable to not hire a fish.

Re: I don't need your query language

#46
Perhaps I’m lucky, but I’ve never experienced SQL shaming. What I have experienced is referencing shaming, where I’m allowed to write SQL, but all table references in that SQL need to come from the model instead of being hard-coded in the SQL. I suppose it’s nice to have all the join tables’ models being included in the file. It makes it easy for a search to find all the usages in case there is a big refactor. It also makes the SQL look a lot more complicated then it really is and a lot less clean then these examples- at least in the code.

Re: I don't need your query language

#47
I don’t really find the examples convincing. Like, I get that sql could maybe be written in a slightly less horrid way but I would prefer something a lot less horrid.

I think I’m much more motivated by analytics queries than the kinds of thing in this example though. I find sql is poorly suited in this case because it is verbose and written backwards, and often requires many layers of subqueries. That said, one can usually still express queries in SQL that other systems do not allow.

For these kinds of queries I think there are just better ways to express them. Another issue with sql is that has some quite strange semantics.[1]

An example query I wrote yesterday is:

  select group, min, max, (max-min)/1e9 range
  from
    (select group, min(size) min, max(size) max
     from
       (select time, instance, sum(size) size, regexp_replace(name,…) group
        from X
        group by regexp_replace(name,…), time, instance)
     group by group)
  order by range desc 
  limit 10
Which is neither pleasant to write nor iterate on interactively.

With something like dplyr instead:

  X %>% mutate(group=regexp_replace(name,…))
    %>% group_by(group,time,instance)
    %>% summarize(size=sum(size))
    %>% group_by(group)
    %>% summarize(min=min(size),max=max(size),range=(min-max)/1e9)
    %>% arrange(-range)
    %>% head(n=10)
And that can be built up interactively pretty easily by adding onto the end of the pipeline.

I would also note that, due to sql being painful, the query is not exactly the one I wanted and instead I would have wanted something better capturing the change over time, but the thought of doing that in SQL seemed too unpleasant.

An example of an actual query language that tries to be better for analytics: https://prql-lang.org/

[1] from someone who spent a lot of time working on databases and sql: https://www.scattered-thoughts.net/writing/against-sql and just on semantics: https://www.scattered-thoughts.net/writing/select-wat-from-s...

Re: I don't need your query language

#48

Show me an elegant SQL version for the queries in this article: https://www.timestored.com/b/kdb-qsql-query-vs-sql/ Particularly when you are trying to run queries where order matters, e.g. top 3 posters by topic on HN. You will find it much more annoying. Fundamentally SQL is based on the concept of tuples/sets which have no order so there's no way to avoid it being messy. What you want is a database based on the co…

It's easy to cherry pick. I guarantee you there are a lot more queries that are easier to write in SQL than in your favorite FancySQL (or even worse, NoSQL) variation.

Re: I don't need your query language

#49

SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…

Yup, this right here. This aspect of SQL is overwhelmingly why I insist on ORMs, too. Any efficiency gains you get by having a senior dev write raw SQL for a complex query are immediately negated by a junior turning what an ORM would write as a single query into three DB calls. All because SQL insists on a flat result set you have to turn into a nested collection yourself, without an ORM doing it for you with eager loading.

Re: I don't need your query language

#50

If this is about NoSQL databases, I dont think SQL is useful for databases which does not follow first normal form. But any alternative to SQL for relational databases will fight an uphill battle. While SQL is somewhat clunky, it is also deeply entrenched.

SQL selection works perfectly on tables in poor normal forms. If you have the columns you need to query pre-joined into the table you’re querying, you just skip the joins. Updates are what gets fun if you don’t have normal form.
Post reply on HN