Re: Object-relational impedence

From: JOG <>
Date: Mon, 3 Mar 2008 14:18:19 -0800 (PST)
Message-ID: <>

On Mar 3, 9:50 pm, Robert Martin <> wrote:
> On 2008-03-03 10:52:10 -0600, JOG <> said:
> > On Mar 3, 2:07 pm, Thomas Gagne <> wrote:
> >> All attempts by applications to access a DB's tables and columns
> >> directly violates design principles that guard against close-coupling.
> >> This is a basic design tenet for OO. Violating it when jumping from OO
> >> to RDB is, I think, the source of problem that are collectively and
> >> popularly referred to as the object-relational impedance mismatch.
> > I wondered if we might be able to come up with some agreement on what
> > object-relational impedence mismatch actually means. I always thought
> > the mismatch was centred on the issue that a single object != single
> > tuple, but it appears there may be more to it than that.
> 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? A single application may be required to process data in several ways - and some may be initially unforseen, as requirements (inevitably) may change?

> RDBs partition data
> based on how many different applications will need to access that data.

...or based on the different ways a single application will need to process the data, no?

> This really isn't an impedance mismatch. It's a mismatch of intent.
> When designers use each strategy for what it's good at, there is no
> mismatch at all.
> > 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.

> --
> Robert C. Martin (Uncle Bob) | email:
> Object Mentor Inc. | blog:
> The Agile Transition Experts | web:
> 800-338-6716 |
Received on Mon Mar 03 2008 - 23:18:19 CET

Original text of this message