Re: Object-relational impedence

From: Marshall <marshall.spight_at_gmail.com>
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.

One's requirements dictate data with certain functional dependencies. Among the easiest tasks in application design is one of the earliest: structuring the data. The RM structures data as relations. Relational structures lack query bias, which is one of the reasons why SQL is so good at ad hoc queries (compared to the other choices.) OO structures mandates an object structure (unsurprisingly): out the gate, one has no choice but to build in a query bias, whether one wants it or not.

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

Original text of this message