Live data from Hacker News

Rethinking Database Programming

acadia.engineering

81–90 of 167 posts

Re: Rethinking Database Programming

#81
post #73

Earlier quoted context omitted.

SQL is a horrible language. I’d gladly program in something composable like Elm.

Agree. Datalog could be a better alternative: https://datalevin.org/docs/preface

Datalog is awesome but I just don't think it's going to get mainstream adoption at this point.

Re: Rethinking Database Programming

#82

By now I stopped counting the attempts to replace SQL. There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different. OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development. Though SQL can be improved, even with my average S…

SQL is based on the relational model but doesn't really conform to the mathematics e.g. doesn't exhibit set semantics.

Re: Rethinking Database Programming

#83
post #12

So this is capable of turning a one-liner of SQL into six lines of barely readable code?

It seems that is the price you pay for the power to turn a 600-line nightmare SQL query into 60 lines of barely readable code.

I'd rather take the 600 lines of SQL, provided it's not dynamically constructed. SQL is a very high level language, it's fine IMO.

Re: Rethinking Database Programming

#84
post #70

Earlier quoted context omitted.

I'm curious what you meant by the web app use case and why you find SQL bad?

He probably is still drinking the NoSQL koolaid of 2015 :)

Just as with any kind of programming I want to be able to detect as much amount of issues as early as possible. That includes issues like invalid queries (both on syntax and types level) but also stuff like will specific transaction isolation level be just enough (from correctness and performance point) for my specific use case, or will the migration query lock the whole db or take multiple days to execute because I didn't know some niche quirk. To me it is obvious that you will not beable to do that with SQL, one because it is old so it accumulated all the weird quirks, that were done in the name of backward compatibility, two is that by it's nature of being script language you just could not do more complicated cross query static analysis. See also https://www.scattered-thoughts.net/writing/against-sql which nicely describes other issues. See languages like PRQL for better syntax, or https://www.languagesforsyste.ms/MixT/ for static analysis possibilities

I am mostly aligned with the article on what I want from next generation of web development. But I don't think using specific library in a specific language or specific query language is a viable long term solution. Hance the mention of Substrait. The solution that I think is needed, is something like LLVM but for databases.

As for the NoSQL, I think it was the worse thing that happened to databases in the last 20 years, probably more

Re: Rethinking Database Programming

#85
Some interesting features here:

- sum types/ADTs have been long missing from database data modeling and this is welcome change. It's not entirely clear to me how the migration strategy here will work with things like removing a variant, etc.

- first class enforced RLS - this seems like a fantastic way to ensure safety/security guarantees. Secure by construction is always preferable to bolt-on security controls.

- composability with a strong module system. I think this will work well in ensuring large schemas can evolve over time. I wonder if there will be package manager in the future.

Re: Rethinking Database Programming

#86

By now I stopped counting the attempts to replace SQL. There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different. OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development. Though SQL can be improved, even with my average S…

SQL has one flaw: The verb should come last. So, "FROM users WHERE id = 1 DELETE" or "FROM users WHERE email = 'foo@example.com' SELECT id". That'd cut back on some accidental "oops I dropped the whole table" because I submitted a delete query before writing the where clause.

Other than that, it's perfect, no notes.

Re: Rethinking Database Programming

#87

Earlier quoted context omitted.

SQL is end to end type safe.

Isn’t sql weakly typed? Or does this depend on the engine?

SQLite is the only one I know of that doesn’t enforce types by default, but I don’t know what the SQL spec requires.

Re: Rethinking Database Programming

#88

Oh man. If this lobste.rs comment is correct about the subscription terms then this feels like a really hard pill to swallow: https://lobste.rs/s/ykq7ym/rethinking_database_programming#c... Still might be viable, but would be tricky to sell. > SUBSCRIPTION TERMS > This license is subscription-based and will remain valid only for the duration of your active subscription. Upon expiration or termination of your subscrip…

I mean, it's the same for - say - Photoshop?

Re: Rethinking Database Programming

#89
post #64

Earlier quoted context omitted.

Isn't SQL already a logical abstraction language over a "physical layer"? I'm not updating indexes or deciding when to flush or fiddling with MVCC when I write SQL

The comment mentioned partioning schemes which is defined using SQL but belongs in the physical layer. Indexes are also defined in SQL.

Thanks. Indices are defined in SQL, but they're not updated in SQL. Once defined, an INSERT/UPDATE updates relevant indexes automatically. That's the abstraction layer SQL provides.

Re: Rethinking Database Programming

#90

By now I stopped counting the attempts to replace SQL. There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different. OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development. Though SQL can be improved, even with my average S…

SQL is based on the relational model but doesn't really conform to the mathematics e.g. doesn't exhibit set semantics.

Can you elaborate?

It can't express every mathematical set operation, but it does have UNION, EXCEPT, and INTERSECT.

Post reply on HN