Totally agree. I only use Postgres on my stuff now (MySQL in a pinch if there's legacy reasons). I got burned too many times by ORMs.
The other point is that the data is the most important part of the application in most cases. Understanding how the data fits together, how it's structured and stored, and how to make sure it doesn't corrupt, is one of the key tasks in creating a system. ORMs don't help with this, but SQL forces us to think about the data. Which is good. I can't count the number of bad architectural structures that seemed like a good idea at the time but that I've had to discard (thankfully in the end) because the database told me they wouldn't work.
SQL doesn't fit every use case. Ansi-SQL being the standard, has been extended on by most vendors. I too often get frustrated by the idea of learning some new query dialect, but context matters.
In the case where a vendor creates something that looks like SQL, it's frustrating if the basics that I expect from ANSI-SQL aren't there. This especially if my data is stored relationally.
If the database/store doesn't behave or store data relationally, SQL often doesn't work well. At least you need some mechanism which the vendor might not want.
I can't expect to use SQL for a graph database. It also might not work so well for a KV store that doesn't have relations/joins.
MongoDB's query language is actually good. I know they support SQL on the enterprise product, but it feels like a compromise.
I suppose the rant has some merit, but I'm trying to say that SQL can't solve everything.
An interesting project is Apache Calcite, which gives a single SQL query model to various data stores. Perhaps one could write a plugin if they really want to use done random database that doesn't use SQL.
I actually had a spell the other day where I looked at alternatives to SQL, which mostly produced Tutorial D variants. And there are some nifty ones, there are query languages that will compile to specific SQL dialects so that you can keep using a familiar database engine. They just aren't used much.
Somehow, we've come to accept a Babel of general purpose programming languages(albeit mostly centered around Algol variants) but the same really hasn't happened with databases. Either it is a form of SQL or it is pooh-poohed as weird and bad.
And I don't think that that's because SQL got everything right and we should worship vintage language design - I think it's just a case of specialized demand and barriers to entry making the database market move slower. A lot of shops fail even at using basic features of SQL, so maybe it's asking too much to get beyond a passing familiarity with relational concepts and one syntax to interact with them.
The author has a point, and Sql is good when it is a human interacting with the database (that's what it was designed for after all).
But when it comes to software/library interacting with the DB it is simply terrible.
Some times you just want to say say hey, give me this specific data and in that case Sql is the easiest solution.
But if you have more complex model and you have a bunch of parameters and you need to build one or more queries based on these parameters then you are better off with ORM. I think that's actually how the first ORMs got started, people got tired building queries with strings.
A good ORM should map pretty directly and logically to SQL, and in my experience is about convenience more than anything. In all fairness, you practically have to be able to write your own ORM to use an ORM effectively; understanding all the black magic under the hood so it doesn't shoot you in the foot. I still think it's worth it though. There are also very light weight ORMs which take in a sql query and just do object mapping with the result. As with everything, it depends on your use case.
Interesting point of view. I've been toying with the idea of using a controlled form of SQL as a DSL for an API instead of REST routes. Since I code in Clojure, I use a lib called Korma to help me build SQL queries. It has a rather good intermediary format and I started to extend it in order to support "additionnal SQL verbs and keywords".
For instance, consider my home-made CONJURE BY verb. It works like INSERT but with a find-or-create-by flavor. Here is how it looks like on the client side of the api.
I really did this out of curiosity, and actually this works pretty well. Once normalized in an easily parsable format (here s-expr based), it's pretty easy and straightforward to manipulate SQL: extracting where statements, merging them and reinjecting the result in a new query is actually quite easy.
Want to have authorizations on what fields can be read/written by the client ? Well it's not that hard to deep-walk a query looking for unauthorized fields.
Want to return data as a graph of entities like GraphQL rather than as a table or at least resolve foreign keys to the subentity they're refering to ? This should be doable.
What about complex query features ? Joins, filters, conditionals and boolean combinators, limitation on the number of results, grouping, etc ... It's all already here.
This leads me to wondering why are we so opaque about our abstractions ? In my view, the relational model is very useful and convenient and should be extended upon. I don't like the way GraphQL has been implemented (disclaimer: i never used GraphQL): to me it's mostly rebuilding what lies one level below although it is more general than my own proposition since it abstracts away the relational model.
As for ORMs I have nothing against them. Actually with the "abstraction transparency" strategy described above, they would be a very convenient way to write a client for such an SQL-based API : it would essentially boil down to writing an adapter.
Here here. Long live SQL. With Postgres and JSON extensions its super simple to get JSON direct from your database.
There's a special place in hell reserved for the creators of ORM's. Every one I've used is especially awful. The worst has got to be ActiveRecord: a giant, slow and bloated leaky abstraction shit-cake that every Rails TODO list app programmer who can't be bothered to learn SQL seems to love.
The other point is that the data is the most important part of the application in most cases. Understanding how the data fits together, how it's structured and stored, and how to make sure it doesn't corrupt, is one of the key tasks in creating a system. ORMs don't help with this, but SQL forces us to think about the data. Which is good. I can't count the number of bad architectural structures that seemed like a good idea at the time but that I've had to discard (thankfully in the end) because the database told me they wouldn't work.