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

A better SQL in 11 lines of code

prela-lang.org

Post reply on HN
Print view View original

31–40 of 54 posts

Re: A better SQL in 11 lines of code

#31

Post by remywang »

Someone wrote: post #26

FTA: “The motivation for focusing on binary relations is that they generalize functions. Functions are powerful because they compose, making them the building blocks of programs. A function maps every input to a unique output, where as a relation can map an input to multiple different outputs. In a sense, a relation can be viewed as a nondeterministic function” If “A function maps every input to a unique output, wher…

Ah, that's not what I meant to say. You're talking about bag vs set semantics. Prela implements bag semantics just like SQL.

That sentence should say "a binary relation can map an input to multiple different outputs", and that's not a bad thing. It's exactly how binary relations generalize functions, and we want that because that lets us compose binary relations like how we compose functions!

Re: A better SQL in 11 lines of code

#32

Post by remywang »

thrance wrote: post #30
Someone wrote: post #26

FTA: “The motivation for focusing on binary relations is that they generalize functions. Functions are powerful because they compose, making them the building blocks of programs. A function maps every input to a unique output, where as a relation can map an input to multiple different outputs. In a sense, a relation can be viewed as a nondeterministic function” If “A function maps every input to a unique output, wher…

"Binary" applied to a relation just means it links pairs of elements, (left, right) for example. Functions are special cases of binary relations, in that each "left" element is linked to at most one "right" element. But the general case of a relation can have multiple right elements for a single left element. So TFA's correct.

Yes this is correct, thank you.

Re: A better SQL in 11 lines of code

#33

Post by grebc »

You’ve got do a better job selling the title sorry.

I feel like the separation between a query & the query execution plan is one of the benefits of SQL. I trust the database system to do the right thing 99% of the time, and I don’t want to think about that either really.

Re: A better SQL in 11 lines of code

#35

Post by troupo »

remywang wrote: post #24
Planktonne wrote: post #22

This seems harder to read than SQL, and only less verbose if you assume that an SQL database would be built with Prela's limitations in mind, which doesn't feel like a reasonable assumption.

With some syntax sugar it looks almost exactly like SQL [1]. Here I’m showing the unsweetened edition for didactic purposes. [1]: https://remy.wang/blog/prela.html

I think you'd want to format it like SQL blocks to separate various concepts and where data is coming from

    movie.with(
      company.s(country).eq("[us]"
    )
    .and(
      keyword.eq("character-name-in-title")
    )
    .select(
      title
      .and(
        cast.s(person).s(alias).s(text)
      )
    )

Re: A better SQL in 11 lines of code

#39

Post by wavemode »

grebc wrote: post #33

You’ve got do a better job selling the title sorry. I feel like the separation between a query & the query execution plan is one of the benefits of SQL. I trust the database system to do the right thing 99% of the time, and I don’t want to think about that either really.

I feel the opposite way. I very rarely trust the database system to do the right thing. Any query more complex than a basic lookup by primary key requires me to look at query plans and validate that indexes are in place and are being used. Otherwise we risk the production server grinding to a halt.

Personally I'd love a more explicit form of SQL that allowed specifying things like "select via scan" or "select via index lookup". (I don't think this HN submission is that - I'm just saying generally.)

Re: A better SQL in 11 lines of code

#40

Post by wbadart »

remywang wrote: post #37
wbadart wrote: post #36

The core relation composition operator reminds me of Alloy's dot-join operator [1]. Wondering if anyone can comment on the differences, theoretical or practical? [1]: https://practicalalloy.github.io/chapters/structural-topics/...

They are exactly the same!

Cool! That's both unsurprising, given the apparent similarities, but also a little surprising, since Alloy is built on relational algebra, which you're very careful to distinguish from TAR in your paper. (Great read, btw!)
Post reply on HN