What's Wrong With ORM

> Nigel Hamilton <nigelturbo10.com> wrote:
>> Why do we even have an ORM problem?
>> It seems like eons ago that programmers suffered
from limited diskspace
>> ... back then normalisation was required to break
things into multiple
>> 'related' tables to avoid data being repeated.
Thanks also to the tyranny
>> of disk seek times and the need for indices the
relational model was born
>> along with the database management systems to
police it.
>
>> But things are moving on - we've got lots of disk
and tons of RAM. Who
>> needs tight 70 pants when you can hang loose? 
>
> A relational database is a collection of facts, and
normalising them is a
> way to ensure there are no contradictions. If you think
DRY is just a
> memory-saving optimisation, you've rather missed the
point.
>

Hmmm ... my point was that some of the itches the relational
model sought 
to scratch (optimising disk retrieval and storage etc) are
no longer as 
itchy. Which presents an opportunity ...

The relational model is great for facts. But my other point
was there is 
an interaction layer on top of the facts. If we all thought
like Mr Spock 
a universe of facts would be fun.

I don't know about you, but I spend most of my time
shoe-horning the real 
world into relational facts. Sadly the world is constantly
changing and 
there is always a tension between the real world and the
relational model. 
Either the model changes, the real world plays along, or you
get a total 
disconnect (we need a new system!!!).

But now we've got more flexibility (more RAM, disk etc) and
we can overlay 
the relational model with something more exotic ... a new
type of ORM 
layer ... and I was suggesting a place to look is in
modelling how people 
actually/truly/really use the information - not the
information itself:

 	|  Interaction Layer |
 	|----- this bit -----|

 	 0
 	\|/ -----> Object -----> RDBMS
 	/ \

NIge

Nigel Hamilton wrote:
> Hmmm ... my point was that some of the itches the
relational model 
> sought to scratch (optimising disk retrieval and
storage etc) are no 
> longer as itchy. Which presents an opportunity ...

I read an interview with Jim Starkey[1] recently who seems
to be 
interested in similar lines:

   http://www.interbase-world.com/en/community/interv
iews/577.php

-Dom

[1] Creator of Interbase, now Firebird.

Nigel Hamilton wrote:
> 
>> Nigel Hamilton <nigelturbo10.com> wrote:
>>> Why do we even have an ORM problem?
>>> It seems like eons ago that programmers
suffered from limited diskspace
>>> ... back then normalisation was required to
break things into multiple
>>> 'related' tables to avoid data being
repeated. Thanks also to the 
>>> tyranny
>>> of disk seek times and the need for indices the
relational model was 
>>> born
>>> along with the database management systems to
police it.
>>
>>> But things are moving on - we've got lots of
disk and tons of RAM. Who
>>> needs tight 70 pants when you can hang loose?

>>
>> A relational database is a collection of facts, and
normalising them is a
>> way to ensure there are no contradictions. If you
think DRY is just a
>> memory-saving optimisation, you've rather missed
the point.
>>
> 
> Hmmm ... my point was that some of the itches the
relational model 
> sought to scratch (optimising disk retrieval and
storage etc) are no 
> longer as itchy. Which presents an opportunity ...
> 
> The relational model is great for facts. But my other
point was there is 
> an interaction layer on top of the facts. If we all
thought like Mr 
> Spock a universe of facts would be fun.
> 
> I don't know about you, but I spend most of my time
shoe-horning the 
> real world into relational facts. Sadly the world is
constantly changing 
> and there is always a tension between the real world
and the relational 
> model. Either the model changes, the real world plays
along, or you get 
> a total disconnect (we need a new system!!!).
> 
> But now we've got more flexibility (more RAM, disk
etc) and we can 
> overlay the relational model with something more exotic
... a new type 
> of ORM layer ... and I was suggesting a place to look
is in modelling 
> how people actually/truly/really use the information -
not the 
> information itself:

I'm fairly sure what you actually want here is an RDF
store, perhaps one with 
OWL integration into $language_of_choice

http://gigaton.thoughtworks.net/~ofernand1/DeepInt
egration.pdf

is a mine of ideas on the subject, and there are already
some rather cool perl 
modules for straight RDF usage in perl, notable RDF-Helper
(which I believe is 
currently only in sf.net CVS rather than on CPAN but very
promising indeed).

There's also been some interest in making RDF an
alternative store for 
DBIx::Class, but whether that'll turn out to be a good idea
or not I can't 
really say at this stage 

-- 
      Matt S Trout       Offering custom development,
consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class
and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for
more information

+ Help us build a better perl ORM: http://dbix
-class.shadowcatsystems.co.uk/ +