
I don't want to learn your garbage query language - wanned_man
http://erikbern.com/2018/08/30/i-dont-want-to-learn-your-garbage-query-language.html
======
marcus_holmes
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.

------
nevi-me
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.

------
annywhey
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.

------
zaro
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.

------
caseymarquis
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.

------
GorgeRonde
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.

(conjure my-record (by {:linked-record-id 1}) (values {:field "abc"}))

Upon reception, it is translated into requests with classical SQL verbs

(let [existing (select my-record (where {:linked-record-id 1}))] (or existing
(insert my-record (values {:field "abc" :linked-record-id}))))

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.

------
bausshf
I just want to point out that some ORMs let you use SQL queries directly and
thus you don't need to know much more than your model's layout.

------
tannhaeuser
Ever worked with younger Java devs? They're so entrenched in JPA (Java ORM
interface) they think it rather than SQL is the standard query language.

------
iamleppert
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.

