A better SQL in 11 lines of code • Hacker News Board

Re: A better SQL in 11 lines of code

#51

Post by bluenose69 » Sun, Aug 30, 2026, 9:16 AM UTC

amluto wrote: post #27

prathje wrote: 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…

Re the title possibilities: some films have multiple titles. "The F Word", a Canadian film, was called "What if" in the USA ... I guess to avoid scaring away people who thought it was porn. (It's not. It is funny and sweet. And realistic, in a quite-unrealistic way.)

Re: A better SQL in 11 lines of code

#52

Post by arunix » Sun, Aug 30, 2026, 11:25 AM UTC

kamma4434 wrote: post #49

slowcache wrote: post #9

I 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…

There is no good ORM -like it says here https://github.com/l3nz/ObjectiveSync “Bad practice - if you hide the database, you may get something done quickly, but it's a bad idea. If yor Java code expects to have a collection of one million objects as an array, it does not matter if they are lazily loaded or not - some code somewhere might want to iterate over them, and this will kill the process. You cannot really forg…

ORMs based on the query object pattern don't hide the database, but make SQL more reusable/composable (e.g. SQLAlchemy, JOOQ, etc).

https://martinfowler.com/eaaCatalog/queryObject.html

Re: A better SQL in 11 lines of code

#53

Post by andai » Sun, Aug 30, 2026, 2:45 PM UTC

remywang wrote: post #23

andai wrote: 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.

Very interesting, thanks. You know reading the python implementation was very encouraging, the idea that you could get a very basic relational database from scratch in That sounds like it would make a great educational resource if it were "dumbed down" a little bit, for the layman like me!

Re: A better SQL in 11 lines of code

#54

Post by amluto » Sun, Aug 30, 2026, 6:39 PM UTC

bluenose69 wrote: post #51

amluto wrote: post #27

Earlier quoted context omitted.

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…

Re the title possibilities: some films have multiple titles. "The F Word", a Canadian film, was called "What if" in the USA ... I guess to avoid scaring away people who thought it was porn. (It's not. It is funny and sweet. And realistic, in a quite-unrealistic way.)

Sure. But IMO one should define, as part of the schema, whether one can handle this.