Re: Object-relational impedence
Date: Mon, 3 Mar 2008 16:24:33 -0800 (PST)
Message-ID: <2529df92-51f2-45a6-a903-049caebbb11d_at_i12g2000prf.googlegroups.com>
On Mar 3, 2:18 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Mar 3, 9:50 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
>
> > There is indeed more to it than that. OO and RDB are both strategies
> > for partitioning data. However, the motivation behind the partitioning
> > is completely different. OO partitions data based on the way a
> > particular application will process that data.
>
> Is it really as clean cut as that?
Boy howdy, no, it's not. For one thing, neither OO nor the RM are strategies for partitioning data.
Furthermore, since OOPLs lack physical independence, traversing the graph may be quite expensive, particularly in the case where the graph is backed by storage in a database, which is part of why ORM is such a universally bad idea. Of course, one can always build physical independence into one's objects, but that has to be done manually, one pathway at a time.
> > > One thing I would like to avoid
> > > (outside of almost flames of course), is the notion that database
> > > technology is merely a persistence layer (do people still actually
> > > think that?) - I wonder if the 'mismatch' stems from such a
> > > perspective.
>
> > Take out the word "merely", and recognize that "persistence" is more
> > than just storage.
>
> Perhaps you could expand? I was referring to the fact that databases
> do more than 'persist' objects.
DBMSs don't even necessarily persist at all.
I've said in the past that persistence isn't even a first-tier dbms
feature.
It's a strong second-tier feature, to be sure! But a dbms with no
persistence still has strong use-cases. Which makes it clear enough
that anyone who considers SQL to be about persistence *primarily*
(if not exclusively) hasn't yet identified what the first-tier feature
even *are.*
Marshall Received on Tue Mar 04 2008 - 01:24:33 CET