From: Robert Klemme <shortcutter@...>
Date: 2010-11-15T02:20:20+09:00
Subject: Re: ORM's - Don't Do It!

On 11/13/2010 02:35 PM, Phillip Gawlowski wrote:
> On Sat, Nov 13, 2010 at 10:54 AM, Mike Stephens<rubfor@recitel.net>  wrote:

> Essentially, the data that you store in a database, any database, has
> to be massaged such that you can store it in the first place. AKA
> normalization.

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.

>> A language like SQL gives you a neat interface between the two worlds.
>
> 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. :-)

>> It is trivial to adjust an SQL call wrapper even if you need to. Any
>> minor extra burden on connecting from your Ruby program is more than
>> compensated by the  more sophisticated (more precise) representations of
>> the data and the wealth of other database tools and services (stored
>> procedures, triggers etc) made available to you.
>
> In how far is SQL's representation of data "more sophisticated"? In
> the end, the rows returned by an SQL query are nothing but an Array
> (maybe a Hash with the SQL query as a key in Ruby parlance).

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

> Since Triggers operate on the SQL statements, which the programming
> language<->  SQL DB interface *has* to use (no matter if it is shelled
> out to the command line, uses ORM, or JDBC), you don't lose the any
> capabilities your SQL DBMS offers you, since those operate on the SQL
> statements (they have to, since you don't have to interact with a DB
> with its vendor-supplied driver).
>
> However, the abstraction offered by, say, ORM, allows the programmer
> not to have to *care* about the underlying database, so he doesn't
> have to care about the SQL used. Which, considering the ugliness of
> SQL, is no small blessing.

This is the standard argument for ORM and it is true in many situations. 
  However, there are some grains of salt to be taken with this: 
unfortunately the exact fact that you do not have to care about the DB 
underneath can lead to serious issues because it lowers the awareness 
level for database peculiarities - and I am not only talking about 
differences in SQL dialects.  The more important things that someone 
creating an application which uses a RDBMS should be aware of are 
concurrency models and performance.  If you create an application which 
is exposed to the internet (or any other potentially "unlimited" number 
of users) you need to take these aspects into consideration otherwise 
you'll learn too late that the design you chose does not work. :-}

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

Kind regards

	robert