Hacker News new | ask | show | jobs
by HelloNurse 15 days ago
Even wilder:

> SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges.

Forgetting that interactive SQL queries, and to an even greater degree the underlying databases, are applications.

2 comments

Anyone who hates SQL typically is completely clueless how hard it is to actually do what SQL does correctly and efficiently.

SQL makes doing something that is VERY hard stupidly easy.

Feel free dismiss my option by assuming I'm some ignoramus that doesn't know anything about how databases work.

I'm well aware of the underlying challenges that SQL provides convenient abstractions over, and what I'm saying is that it actually isn't all that helpful for complex use cases unless you know a decent amount about dbs; which at that point, I'd rather program against a thinner , less abstract persistence API.

The flip-side of what you've stated is that SQL makes doing things that that SHOULD be hard, because they are stupid, stupidly easy. For instance, it's dead simple to make read queries with complex filters that join together an arbitrary number of tables and transactional updates that change values in rows across multiple tables. However, on large datasets or application that need high throughout, relying on those kinds of queries would be a terrible idea.

Furthermore, databases like Postgres use SSI by default which means that complex transactions that mix reads with writes can have subtle and hard to catch bugs that are completely non-obvious to new comers. I could easily forgive a junior developer for thinking they could implement an accurate counter in postgres using a transaction with a select then update to increment a value in a given row.

The issue is that most of these tools try to reinvent the wheel. Instead of using sql, you use 'fluent builders' or whatever, and they have their own tricks and cevats.

Sqlc is the best thing I've personally used because it produces models and repositories based on plain sql queries.

It's much easier to reinvent one of the most used tools in the world as a far worse version than better.

It's almost as if it was easy to reinvent something highly used that someone would've already done it...