
ORM Is an Offensive Anti-Pattern - mariuz
http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html?2014-48
======
anonfunction
Reminds of a great anti-orm article written from 2006 by Ted Neward entitled
"The Vietnam of Computer Science"

[http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...](http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx)

~~~
bibonix
It is actually cited inside

------
smt88
SQL sucks, too. I hope we start to see every web framework come with a better,
more expressive wrapper for SQL rather than the compulsory ORM.

~~~
yegor256a
It sucks when you don't understand it, like any other language/technology :)
When you understand SQL, it is a powerful implementation of a relational
calculus

~~~
smt88
Been writing SQL for 10 years. I definitely understand it.

The problem is that it's rigid, and constructing queries based on filters or
user input is painful. It disrupts the flow of your code.

That's why I now use query builders, which aren't ideal, but they at least
allow me to build my queries in a logical order (adding additional ORDER BY
conditions, adding/removing JOINs depending on my needs, etc.)

The problem is that no query builder that I've used flows as well as SQL or
"gets out of the way".

------
magikid
Isn't he just advocating for having a Model (ala MVC) on top of an ORM? That
seems to be exactly what most frameworks using an ORM have done.

------
borplk
I generally agree with the ideas presented but I think we miss an even larger
point.

I should probably write this at a better time as a blog post, but briefly:

Why are we trying so hard to "abstract" out the database? If you have done any
significant SQL work you'd agree that no ORM or abstraction can ever hope to
beat the expressiveness and power of raw SQL.

We have spent decades trying to reduce all these awesome database technologies
down to their lowest common denominator so that you can switch databases in
and out and as if they are not important.

Most software revolves around data, software mostly is data. So if you can
treat your database layer as a blob-store you are not making good use of it.
Database in my view is such a core piece of technology that I pick one, and
the right one, and stick to it and make use of its capabilities to the
maximum.

And we have spent decades trying to adapt SQL into programming-language-
specific concepts. We have to grab SQL and twist and turn it with some
similarly named half-assed SQL pasta function chain to imitate SQL.

So my point is this, why don't we try to make the programming languages adapt
to SQL, instead of the other way around?

Every non-trivial piece of software needs some form of data persistence with
querying and sorting and ordering and all that good stuff that SQL does.

After this long, as far as our programming languages are concerned our SQL
queries are still plain 'strings'.

I think there should be a tighter integration, and acknowledgement from those
making the languages, that hey, every half-serious user is going to be using
SQL with this thing.

One idea could be something along the lines of 'literal-sql' syntax. To
'upgrade' SQL from being a plain string into something that the language
acknowledges.

Then the compiler could do a whole lot more. The language/compiler could be
made aware by some mechanism about the database layer so it could figure how
to turn your DATETIME column into the corresponding type in the programming
language and vice versa.

And you could write something like "DateType myDate = <SQL>SELECT date from
posts</SQL>;".

The model-based ORM does not make it easy for you to query custom fields
because it tries to package everything into a box.

I think the programming languages need to embrace and accept SQL as a first-
class citizen.

The compiler could potentially be able to connect to the database and generate
some type-safe classes for use from the schema.

Ada with the GNATColl package is the closest thing to this idea I have seen.

It can inspect the schema and generate rock-solid type-safe classes for use
with database.

It frees you to make full use of the power of your database instead of
crippling it.

Edit: Put another way, after all these years the way programming languages
treat data persistence is virtually unchanged. The attitude is stuck mostly at
"ehh whatever just open your socket/file and write the bytes... I don't care
if it goes down the drain or to a database".

I think there lies some potential for a next-generation change. The
programming language and the database can work a bit more closely together, I
don't mean in an interactive or real-time way but basically the
compiler/tooling could say "hey we know everyone is going to need to save
these things into some database at some point and get them back ... so let us
help you with that ..."

It could in the form of an inspection step that you can trigger and it could
say 'ok I see you've got these 20 tables that you are interested in and that
column from that table is a boolean with a not null constraint so I'll watch
out for that when you are writing your queries...' sort of thing.

Obviously statically and strongly typed and generally more 'safe' languages
would have an advantage here because they can know more about your program
statically.

Sorry it's a bit late and that's not in the most coherent way I could put it,
just quickly typed it up for the sake of visibility and discussion.

~~~
yegor256a
Even though it sounds interesting, I believe that object-oriented programming
has nothing to do with relational calculus. They are two different and very
powerful things and they should stay separate, in order to stay powerful.
There has to be a thin bridge between them (like JDBC). But again, I strongly
believe that they should not affect each other.

