[zmmmmm]

I think it'd be a moot point if SQL wasn't painful and awkward to work with in the first place. But database purists control it and won't let go, so we will have to live with everyone else inventing layers to make their lives easier.

[dewey]

For me this feels like the complaints about error handling in Go. People who work with it all the time, don't even think about it past the first week. If you are starting out it might bother people because they are not used to it.

Personally I really like working with SQL and find it quite elegant, I always encourage people to use it as it really is a job-superpower if you can just dig up issues directly in the DB quickly. It has a long history so for every question you have there's many answers or avenues to ask them.

[umanwizard]

I spent 5 years working on a SQL database (materialize.com) and I think SQL is awful.

https://www.scattered-thoughts.net/writing/against-sql (by another former Materialize employee) is a good takedown.

[deergomoo]

I agree with the GP’s point that people should probably just learn SQL, but there are things about SQL that are objectively bad, especially from the perspective of a software developer.

It’s not a very composable or consistent language, so I think it makes total sense that we see so many abstractions over it.

[jeltz]

The issue with the abstractions over SQL is that while they fix some problems they always introduce a bunch of new problems so in the end SQL is still preferable. I have yet to see an example where that is not the case.

[setr]

The fundamental issue is that they have to generate SQL at the end of the day, so there’s a hard limit on how much you can really change. I don’t know why every database treats SQL as the only API, even Postgres. Even the extension systems, which have the opportunity to hook directly into DB internals (and has no standardization to bother meeting) end up with SQL as the API to do actual db operations.

[anarazel]

> Even the extension systems, which have the opportunity to hook directly into DB internals (and has no standardization to bother meeting) end up with SQL as the API to do actual db operations.

FWIW, nothing forces an extension to do so. I'm pretty sure there are several that do DML using lower level primitives.

[deergomoo]

For me query builders are the quintessential example. Not ORMs, just thin layers that allow you build up a query in pieces.

If you have cases where you might need to conditionally join, or have any reasonably complex filtering based on input, building up a plain SQL statement using string interpolation at the call site gets very messy very quickly.

[jeltz]

I have used many query builders and experienced both the upsides and the painful downsides. The by far best one I have used has been JOOQ (Lukas Eder is a genius who really understands SQL well) but even that often causes more pain than it helps. Compared to the issues caused by them I in most cases prefer string interpolation of SQL.

[zmmmmm]

Take the simple example of joining via foreign key to another table in a parent child relationship. SQL makes you redundantly specify the other table even though it is fully defined by the foreign key relationship. Purists will say "what if you actually want to join on some other column" or "what if there are multiple foreign key relationships" and a plethora of other "what ifs" and all these ignore the reality that 99.99% of the time it is completely unambiguous and they are just happy that millions of developers all around the world are uselessly typing redundant terms into queries. This is what leads people to eventually say "screw it, I'm scratching that itch" and we have "yet another abstraction layer".

[jimbokun]

I like Go a lot and can work with it's error handling paradigm, but I still often wonder if the same semantics could be accomplished with less verbosity in a way that makes the underlying algorithm more clear when reading the code.

[jahsome]

I've always felt the "verbosity" is a feature.

Verbosity is in the eye of the beholder; To me, it's the verbosity of error handling that makes the algorithm clear. Of course I recognize with others that opinion probably changes depending on whether the person reading a given bit of code views error handling as part of the algorithm.

[KronisLV]

> People who work with it all the time, don't even think about it past the first week.

I think SQL is often quite awkward, at least when you look at people exploring alternatives, like https://prql-lang.org/

Not just “the standard” variety, but also all of the vendor specific varieties that you’ll use in practice (MySQL/MariaDB, PostgreSQL, SQLite, Oracle, SQL Server etc.) and how the features offered by each differ, how the support for custom types differs, how the procedural languages differ, the actual experience of using them, seemingly half baked error messages when compared to most imperative languages, varying support for getting the query optimiser to do what you want (e.g. hints), query plans that aren’t pleasant to stare at, often no support for automated analysis of how things are running and suggestions for indices (e.g. Oracle had that sort of feature, it is sometimes helpful, but the automatically generated indices are or at least last I checked were treated as their own special thing and you couldn’t easily delete them). Even things like varying support for working with geospatial data, JSON or time series data.

Not just that, but also the tooling (or the lack of it) - good luck debugging the execution of stored procedures in your DB or placing breakpoints in there, good luck hooking up observability/tracing solutions as easily as you would for your back end, good luck debugging why your database link calls take 100x longer when executed through JDBC in your app but not in the developer tooling.

Not that ORMs or NoSQL make everything much better, you’d just trade one set of annoyances for another, especially when you end up trying to generate dynamic SQL with the likes of myBatis XML mappers. Don’t get me started on people over fetching or ending up with N+1 problems with most ORMs, or executing bunches of queries against the DB just to retrieve some data that you might as well get in one go with a well crafted DB view. Not that you can’t make your DB schema a mess as well with a liberal application of EAV or OTLT (or just attempting to make polymorphic links).

I think SQL as a language makes sense, but PRQL often feels more sensible. I feel like the current RDBMSes out there are very powerful, but that there are also aspects about them (and the differences between the ones you’ll use) that absolutely suck. It feels like where back end languages are getting progressively better DX, databases instead gave us… CTEs? Some syntactic sugar for JSON in PostgreSQL? Feels like they move painfully slow.

For what it's worth, that's why I welcome every new tool or attempt at improving things, even if they won't replace the usual enterprise stacks of having some RDBMS, a JDBC/ODB/whatever driver and probably an ORM on the back end.

[consteval]

I truly have never understood this mentality. To me, SQL is very convenient and quick to work with. It's extraordinarily painless.

I've done data processing in Perl and Python before. THAT is painful. What I think people don't realize is that doing procedural "querying" in a typical PL is, like, 10x the amount of code as an equivalent SQL query. I don't see how the alternative is much better.

SQL just doesn't work like a typical PL, but that's a good thing.