NYCPHP Meetup

[Paul Houle]

Hans C. Kaspersetz wrote:
> ORM is a beautiful thing.  We are using ORM extensively on a large 
> financial application and it works absolute wonders.  It has made many 
> non trivial tasks, especially those that involving very complex 
> objects that span many tables, very manageable.   I was not a believer 
> at first, I thought it was complex and unpredictable.  I wasn't sure 
> what I was going to get back from it at any given time.  However, with 
> refinement and practice our ORM system is very predictable and saves 
> tons of time.  It can be done, it just takes time to develop.  I have 
> a debut of gratitude to Andrew Yochum and Chris Hendry.  They did a 
> fantastic job implementing it.
>
    Is this a system you've built in-house?

    I've certainly seen places where ORM was as much of a problem as it 
was a solution.  On the other hand,  I've done more than my share of 
maintainance on applications where sql code is distributed throughout 
the application,  and (worse) applications where people developed a 
database layer which encapsulated bad practices and bad assumptions 
about the problem domain.

    One basic trouble with ORM is that it violates the principle of 
"don't repeat yourself;"  you have to maintain a database schema ~and~ 
an object hiearchy.  Change one,  and you have to change the other.  
Another problem is that there is a semantic mismatch between objects and 
sql -- there are three ways to represent inheritance relations in sql,  
and all three are unsatisfactory in some way.

    I've been working lately with a minimalist "active record" that 
introspects the database,  and lets you write something like

$table=$db->{my_table}
$row=$table->fetch($id);
$row->{count_value}=77;
$row->update();

    it saves a lot of fumbling with 'addslashes' or '?' parameters,  
thus eliminating a common kind of repetitive coding.  It doesn't try to 
map database 'rows' to anything else,  but it can still automate certain 
aspects,  such as timestamping changes to rows,  and keeping an archive 
of who changed what when.  I've been trying to develop something that 
does 20% of the work and eliminates 80% of the pain of writing "plain 
old" applications with lots of SQL.  So far the system is 
zero-configuration,  although I'm sure I'll add features to it someday 
that require some configuration -- for instance,  I do see an easy way 
to implement a certain kind of inheritance.

    ORM systems do get interesting,  however,  in architectures that 
really take advantage of the objects.  For instance,  if you can design 
your objects so that aspects cut across them,  you can build really 
powerful systems quick.