Re: ORM's - Don't Do It!

On Sun, Nov 14, 2010 at 6:20 PM, Robert Klemme
<[e-mail]> wrote:

> You would apply the very same reasoning when creating classes for a
> particular problem domain so normalization isn't really that esoteric for
> someone doing OO development.

Absolutely, and I never said otherwise. No matter what tool one uses,
you don't get around the fact that you have to think about what you
are dealing with, how to deal with it, and which tool to use.

>> No, it doesn't. SQL's syntax is unlike any programming language I
>> know. Pure SQL contains no looping constructs, for example. It can
>> only retrieve and store data.
>
> Since the advent of Analytical SQL you can do amazing things in a single
> query. :-)

I'm also aware of the trigonometric and geospatial functions modern
databases provide. Doesn't mean that SQL gets prettier, or any more
useful (the issue actually begets the question of separation of
concerns, which is a whole other kettle of fish).

> I don't think the *representation* is so much more sophisticated - if at
> all. =A0It's the *storage* of and *access* to the data which is extremely
> sophisticated in modern RDBMS. =A0IMHO the two main features of RBDMS are
> efficient management of large volumes of data and maintaining integrity
> (transaction management).

Absolutely. Which is why I happily use an ACID compliant database any
day (unless a simple text file is easier to deal with, but that's only
true in few circumstances, like log files, config files, and such).

> This is the standard argument for ORM and it is true in many situations.
> =A0However, there are some grains of salt to be taken with this: unfortun=
ately
> the exact fact that you do not have to care about the DB underneath can l=
ead
> to serious issues because it lowers the awareness level for database
> peculiarities - and I am not only talking about differences in SQL dialec=
ts.
> =A0The more important things that someone creating an application which u=
ses a
> RDBMS should be aware of are concurrency models and performance. =A0If yo=
u
> create an application which is exposed to the internet (or any other
> potentially "unlimited" number of users) you need to take these aspects i=
nto
> consideration otherwise you'll learn too late that the design you chose d=
oes
> not work. :-}

This is such a generalized statement, it is true in pretty much all
circumstances: You *have* to be aware of the limitations your chosen
toolset has. Using an ORM library doesn't excuse you from thinking
about the database (it "merely" makes working with the DB easier), nor
does the lack of an ORM excuse you from thinking about how to map the
data to the program model.

There are no silver bullets, and every abstraction is a trade off. We
use Ruby, for example, because we prefer an expressive syntax and
dynamic features about the line noise of C despite C's better
performance in some circumstances.

> Just one example: often ORM are ideal to retrieve one or few objects,
> manipulate them in memory and store them later. =A0Even a seemingly simpl=
e
> task like "up salary of everyone in marketing by 5%" can be tedious with
> ORM. =A0Typically "UPDATE EMP SET sal =3D sal * 1.10 WHERE dept =3D 'mark=
eting'"
> is far more efficient than an ORM solution - unless the ORM supports mass
> data updates via special mechanisms.

Obviously. But for mass updates, I rather grab a script and fire that
off against the DB itself, than use a database abstraction layer of
any kind. It's simply faster. Similarly for moving data into a
database. Using an ORM layer and such slows things down too much for
little to no benefit (I'd hate to move any non-trivial dataset via
ActiveRecord and its migration semantics, for example).

TL;DR: No choice of tools is superior in all circumstances. Never was,
never will be. But if you decide to agitate against a specific set of
tools because of what amounts to religious fundamentalism and with
righteous preaching, I'm happy to apply a 4x2 clue any day.

--=20
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.