Live data from Hacker News

A Short Story About SQL’s Biggest Rival

holistics.io

121–128 of 128 posts

Re: A Short Story About SQL’s Biggest Rival

#121

Had expected to read sth about Datalog, rivaling SQL at least in academic DB literature.

Same here. Datalog is superior to both, but alas.

Don't despair. Datalog is alive and well. Yes, it does compose beautifully. However, with composition solved, you'll discover that a naive implementation of relational algebra will suffer from spurious cross products.

https://engineering.linkedin.com/blog/2020/liquid-the-soul-o...

https://engineering.linkedin.com/blog/2020/liquid--the-soul-...

Re: A Short Story About SQL’s Biggest Rival

#122

Earlier quoted context omitted.

Same here. Datalog is superior to both, but alas.

Don't despair. Datalog is alive and well. Yes, it does compose beautifully. However, with composition solved, you'll discover that a naive implementation of relational algebra will suffer from spurious cross products. https://engineering.linkedin.com/blog/2020/liquid-the-soul-o... https://engineering.linkedin.com/blog/2020/liquid--the-soul-...

This is pretty interesting stuff, thanks for sharing! Does temporal information get any special treatment in the economic graph at the moment? Are temporal queries of any interest?

I ask because I work on Crux [0] which at its core is a point-in-time bitemporal Datalog engine, and I see a lot of similarities (schemaless core, Worst-Case Optimal Join etc.)

[0] https://opencrux.com

Re: A Short Story About SQL’s Biggest Rival

#123

Earlier quoted context omitted.

Assuming we key a and b by y.d and generalizing b to sets, we are reaching the limits of the relational model: there is no good way to represent multiple sets associated with a given key, we need independent tables to do so. Neither cross product nor null padding is a good way to represent the schema {y, a[], b[]}. y.d | a | b ------------------- y0 | a0 | b0 y0 | a0 | b1 y0 | a1 | b0 y0 | a1 | b1 y0 | a2 | b0 y0 | a…

# create table y (i int, d int); # insert into y values (1, 1), (1, 2), (2, 1); # select *, (select count(*) from (select count(y.i), y.d from y group by y.d) _) as foo from (select count(y.i), y.d from y group by y.d) _ ; count | d | foo -------+---+----- 1 | 2 | 2 2 | 1 | 2 (2 rows) By the way great example how unwieldy SQL is. A bit better with CTE: # with bar as (select count(y.i), y.d from y group by y.d) select…

Nice! Should be easy to do max instead of count. Then top instead of max. Then top3 breaks the model.

Re: A Short Story About SQL’s Biggest Rival

#124
Quote: "Of course, there was a silver lining to the whole saga. Stonebraker had forked the Ingres codebase in 1982 to create his company. Defeated by the bruising database wars of the 80s, he returned to Berkeley in 1985, and started a post-Ingres database project. Naturally, he named that database post-gres — as in, after Ingres.

And thus PostgreSQL was born."

And 35 years later PostgreSQL is kicking Oracle's butt at every corner.

Re: A Short Story About SQL’s Biggest Rival

#125

Earlier quoted context omitted.

# create table y (i int, d int); # insert into y values (1, 1), (1, 2), (2, 1); # select *, (select count(*) from (select count(y.i), y.d from y group by y.d) _) as foo from (select count(y.i), y.d from y group by y.d) _ ; count | d | foo -------+---+----- 1 | 2 | 2 2 | 1 | 2 (2 rows) By the way great example how unwieldy SQL is. A bit better with CTE: # with bar as (select count(y.i), y.d from y group by y.d) select…

Nice! Should be easy to do max instead of count. Then top instead of max. Then top3 breaks the model.

Yes, should be max(count). I've lost you with top3.

    # select * from
      (select count from (select count(y.i), y.d from y group by y.d) _ limit 2) b,
      (select count(y.i), y.d from y group by y.d) a;
     count | count | d 
    -------+-------+---
         1 |     1 | 2
         2 |     1 | 2
         1 |     2 | 1
         2 |     2 | 1
    (4 rows)

Re: A Short Story About SQL’s Biggest Rival

#126

Earlier quoted context omitted.

Nice! Should be easy to do max instead of count. Then top instead of max. Then top3 breaks the model.

Yes, should be max(count). I've lost you with top3. # select * from (select count from (select count(y.i), y.d from y group by y.d) _ limit 2) b, (select count(y.i), y.d from y group by y.d) a; count | count | d -------+-------+--- 1 | 1 | 2 2 | 1 | 2 1 | 2 | 1 2 | 2 | 1 (4 rows)

top - max value in the group

top3 - max 3 values in the group

Re: A Short Story About SQL’s Biggest Rival

#127
post #122

Earlier quoted context omitted.

Don't despair. Datalog is alive and well. Yes, it does compose beautifully. However, with composition solved, you'll discover that a naive implementation of relational algebra will suffer from spurious cross products. https://engineering.linkedin.com/blog/2020/liquid-the-soul-o... https://engineering.linkedin.com/blog/2020/liquid--the-soul-...

This is pretty interesting stuff, thanks for sharing! Does temporal information get any special treatment in the economic graph at the moment? Are temporal queries of any interest? I ask because I work on Crux [0] which at its core is a point-in-time bitemporal Datalog engine, and I see a lot of similarities (schemaless core, Worst-Case Optimal Join etc.) [0] https://opencrux.com

Aside from what comes for free with "log-structured" there is no special treatment for temporal data.

Re: A Short Story About SQL’s Biggest Rival

#128

Minor point, and others have brought up more details around composability, but I think it's an absolute mistake to reference properties on an object before that object is declared. I.e. if SQL had the FROM clause before the SELECT clause autocomplete support could be much more intelligent about helping with SELECT columns. Same problem with declaring imports in javascript. Python got it correct, where I write e.g. 'f…

I find imports in Python completely backwards conceptually compared to JS. I hadn’t thought about the autocomplete issue though. In practice, I know what I want to import, I guess.

I think it makes more sense the way Python does it. You get all the dependencies more or less in a column on the left, instead of jumbled at different widths on the right side.
Post reply on HN