relational databases have years of reseach into them, not the query language itself.

sql was built so people other than devs can use it, but we got stuck with it.

SQL is horrible as a language to read or write. There’s a million different variants, because it lacks so many basic things. And when used in other code, you generally end up string concatinating one language in another language, with all the HORRIBLE bugs something like that brings about.

Imagine Backend People said we should just write adhoc Javascript for the frontend by concatinating the “correct” code in the backend.

If you’re fine with simple queries, use an ORM of your tech stack. Once you have to understand querying performance and weigh usage patterns, constraints, and cache performance and size, then it’s not about SQL anymore. It’s about understanding the DBMS you use.

Simple queries don’t result in simple SQL. How many joins and subqueries do you think an SQL query would require in order fulfill “Give me the top 10 artists of the 90s whose albums were nominated for the MTV awards but didn’t win”?

In Django looks something like

nineties = (date(1,1,1990), date(31, 12, 1999)
album_range=Q(albums__release_date__range=nineties)
artists = Artists.objects.annotate(
  albums_sold=Sum("albums__sales", filter=album_range)),
).filter(
  album_range,
  nominations__date__range=nineties,
  nominations__won=False
).order_by("-albums_sold")
top_artists = artists[:10]

What if one method wants the result of that but only wants the artists’ names, but another one wanted additional or other fields? In django you could simply use artists.only(*field_names) and each method would provide a different set of field names. What would that look like without a capable ORM? Do you think somebody would refactor the method to add a field_names argument? In my experience the result is a bunch of copy pasted queries that modify the query itself to add the fieldnames.

Another common thing is querying related objects. Say you simply wanted to have information about the record label of the aforementioned artists while handling the artists. A many-to-one relationship (artist has one record label, record label has many artists). You could either artist.record_label while in your for-loop, but that would trigger an query for every artist (1+n problem). Or in django that’s artists.select_related("record_label") and it will get all the record_labels in the same query.
If it’s a many-to-many relationship for example “festivals”, then .prefetch_related() will first select the artists, then make a second query of festivals of those artists, and artist.festivals would be available.

An ORM like django makes that simple. SQL, does not.

So, before we even get to the DB optimisation part (which indices to create, whether a view is better or now, which storage engine to use, WAL size, yadayadayada), there’s an entire interface / language that makes writing bad code very easy.

🤔 interesting. First order logic for querying. I found CozoDB which might be useful. Still not sure about how to map objects to the DB. The tutorial is not very relatable. Lots of numbers and single letters.

Thanks for the hint though. I’ll check it out.

I have seen that this is still a problem, even in established enterprise companies.

“If you don’t know what I know, you shouldn’t be here”

“I don’t make mistakes that end up #3 on the vulnerability list, and if you do, I don’t want you around me”

I find that a gate keeperish attitude.

the translation step from binary (program) -> text (SQL) -> binary (server)

Also, the translation step from binary (program) -> text (SQL) -> binary (server), just feels quite wrong. For HTML and CSS, it’s fine, but for SQL, where injection is still in the top 10 security risks, is there something better?

Does this not answer your question?

I’m absolutely biased as a data engineer who loves SQL, but there are some good reasons why SQL has been the de facto standard for interacting with databases since the 80s.

I find it funny how the people who actually have to wrangle data swear by SQL as awesome, but there are always random hacks coming out of the woodwork, who don’t even look at SQL at all, with sweeping statements claiming SQL sucks because reasons.

It’s like the most opinionated people against SQL are the ones who don’t use SQL.

You can write selects with many joins, as long they are regular and either add a column or reduce the result set. You have to write the joins explicitly though. Just shoving all of the restrictions into the where clause will definitely confuse everybody.

It’s also worth noting that the current entry on OWASP is injection generically. It includes SQL, but it also covers things like HTTP links where you concatenate in unchecked user input. SQL injection by itself may no longer be prominent enough make the list.

I’m also going to put the blame squarely on PHP for SQL injection attacks hanging on for so long, particularly when combined with MySQL. That DB didn’t support bind variables for a long time (maybe still doesn’t?). Other languages may have used a library that simulated bind variables for you. Barring that, they tended to always always always show how to use a sanitation function even if it was the first mention in the first tutorial for the top Google result for “sql [language]”. That creates a culture in the language of writing safe SQL code. Not PHP, though; the sanitation functions were there, but they never gave them the prominence that they so badly needed.