Live data from Hacker News

A better SQL in 11 lines of code

prela-lang.org

21–30 of 55 posts

Re: A better SQL in 11 lines of code

#21
post #15

Examples don't show much more composability comparing to SQL. Even more Prela is heavily based on tuples and has same operation semantics as SQL. Shameless plug: https://github.com/baverman/sqlbind-t

Compositionality is hard to show with a small example because it really only comes through at scale.

If anyone can point me to a huge SQL query, I’ll take it up as a challenge to rewrite in Prela!

Prela’s semantics is based on an algebra of binary relations (unfortunately called relation algebra [1]), not the standard relational algebra.

[1]: https://arxiv.org/abs/2607.26356

Re: A better SQL in 11 lines of code

#23
post #18

Very interesting. I'm not very fluent in SQL, so it would have been helpful to see some more side by side examples. (Since Prela seems a lot more ergonomic!) Though maybe a reader fluent in SQL can compare them mentally on the fly?

Here are some SQL queries from standard benchmarks rewritten in Prela: https://github.com/remysucre/prela/tree/cidr#queries

This is in rust and we’re still tweaking the language, so the syntax is slightly different from the post.

Re: A better SQL in 11 lines of code

#24

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

Re: A better SQL in 11 lines of code

#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, where as a relation can map an input to multiple different outputs”, wouldn’t a binary relation have the same problem? I know they mean to say a binary relation isn’t a relation in that sense, but that text could do with better terminology.

Also, and more importantly, I don’t see how “binary” is essential here. What is essential is the uniqueness constraint. Compare Relational Algebra (https://en.wikipedia.org/wiki/Relational_algebra) with SQL.

Re: A better SQL in 11 lines of code

#27
post #2

Interesting concept which reminds of the operations available in pandas. I disagree though with the statement of SQL needing 20 lines. The given query feels verbose and has lots of redundant conditions. Not saying that it is short but a better analogy could look like this: SELECT DISTINCT an.name, t.title FROM keyword k JOIN movie_keyword mk ON mk.keyword_id = k.id JOIN title t ON t.id = mk.movie_id JOIN movie_compan…

I would go one step farther: the SQL is awkward and long because the SQL language not at all optimized for data that is normalized all the way to binary relations.

And if you’re trying to benchmark one of these binary relationship query tools against DuckDB, keep in mind that DuckDB is heavily optimized for wide tables and is really not heavily optimized for point queries.

(Also, I, personally, would be a bit unhappy with a DBMS that cannot express, as part of the schema, that a movie has at most one or exactly one title.)

Re: A better SQL in 11 lines of code

#30
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.
Post reply on HN