Looks a lot like 6NF ( https://en.wikipedia.org/wiki/Sixth_normal_form )
See first footnote
A better SQL in 11 lines of code
11–20 of 54 posts
Re: A better SQL in 11 lines of code
#12this is utterly fascinating.
thinking of LLM usage... it's so close to how LLMs think anyway, vector similarity also being a binary relation. LLM stops blindly guessing SQL and instead starts navigating data straight away.
Re: A better SQL in 11 lines of code
#13At the bottom is the actual code for the "language", which is only 79 lines.
I found it helpful to read it first and then go back to the article. (On my initial reading I was like, "okay, but what is a Rel?")
https://github.com/remysucre/prela/blob/main/tutorial/prela....
Re: A better SQL in 11 lines of code
#14I think an important benefit of a good ORM is to reduce the translations that you have to do between your mental model of the data and what you are trying to do with the data. Before I started working a lot with SQL, ORMs fit my mental model better since I was more used to imperative programming languages and I thought they were easier to work with. Now that I am very comfortable with SQL, I have to translate an ORM…
The point of Prela is exactly to remove that step of indirection, it gives you ORM ergonomics but compiles directly to operations on the physical columns, skipping SQL. At least for me I find it easier to think in Prela than to think in SQL, especially for complex queries, and I believe you’ll feel the same with some practice.
Re: A better SQL in 11 lines of code
#15Examples 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
Re: A better SQL in 11 lines of code
#16Cool language! I thought dplyr and datalog are both local optima (forget about the three-letter abomination) but I now declare this language the global optimum of query language. > In contrast, Prela can be implemented extremely close to the metal. The Rust implementation inlines operators and compiles them into tight fused loops over raw arrays, running several times faster than DuckDB even without a query optimizer…
On second thought, some skepticism on performance comparison: 1. do both systems access everything from memory? 2. do both systems have the same kind of indices? 3. do either system tradeoff scan performance for faster/acceptably fast updates?
1. Yes
2. No. Prela’s speedup is largely due to indexing. We tried to port the same indexing tricks back to duckdb but it wouldn’t let us. See the paper [1] for details
3. Prela focuses on analytical queries at least for now
Re: A better SQL in 11 lines of code
#17People don't use SQL because it's a good language
Re: A better SQL in 11 lines of code
#18Very 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?
Re: A better SQL in 11 lines of code
#19am i the only one who's not afraid of sql taking up lines? sql thats formatted well is beautiful to read my brain enjoys it. it's way easier to read sql in terms of "what resultset is this trying to build" then it is to pick apart some fluent api lookin orm on top of sql
I am in that club. As someone who quite enjoys writing sql but does not like the big sql strings intermingled in the rest of the code I even wrote a clever little python library that loads the queries from files as a function call, that is, you have a file with a pure sql query with parameterized variables and you call it like "for row in sql.video_search(title_like='bridge', date_after='1964-1-1', date_before='1975-1-1')" Nowhere near an orm, everything just produces a result set.
I am sure there are many projects like it, I suspect it is like static site generators and notekeeping apps, easy enough that everybody just makes their own. But this one is mine, and I have grown quite fond of it and use it in all my scripts. It is a little more magic than I am normally comfortable with. dynamic function generation is a bit of a black art, but having each query as it's own callable unit is super handy.
Re: A better SQL in 11 lines of code
#20Earlier quoted context omitted.
On second thought, some skepticism on performance comparison: 1. do both systems access everything from memory? 2. do both systems have the same kind of indices? 3. do either system tradeoff scan performance for faster/acceptably fast updates?
1. Yes 2. No. Prela’s speedup is largely due to indexing. We tried to port the same indexing tricks back to duckdb but it wouldn’t let us. See the paper [1] for details 3. Prela focuses on analytical queries at least for now [1]: https://arxiv.org/abs/2607.26356
Thanks! Kudos for the great work!