Re: Object-relational impedence

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Mon, 3 Mar 2008 15:50:17 -0600
Message-ID: <2008030315501784492-unclebob_at_objectmentorcom>


On 2008-03-03 10:52:10 -0600, JOG <jog_at_cs.nott.ac.uk> said:

> On Mar 3, 2:07 pm, Thomas Gagne <tga..._at_wide-open-west.com> 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. RDBs partition data based on how many different applications will need to access that data.

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.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |
Received on Mon Mar 03 2008 - 22:50:17 CET

Original text of this message