Re: Object-relational impedence

From: JOG <jog_at_cs.nott.ac.uk>
Date: Mon, 3 Mar 2008 15:06:05 -0800 (PST)
Message-ID: <16b5be20-78df-49db-a6b0-a902d9bcf3fc_at_e25g2000prg.googlegroups.com>


On Mar 3, 9:57 pm, topmind <topm..._at_technologist.com> wrote:
> On Mar 3, 10:54 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>
>
> > topmind wrote:
> > > JOG wrote:
>
> > >>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.
>
> > >>I was hoping perhaps people might be able to offer perspectives on the
> > >>issues that they have encountered. 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.
>
> > > This came up in a nearby message. I borrowed the following text from
> > > wikipedia:
>
> > The text had too many blatant errors to start enumerating them all.
>
> Most of them are statements about philosophy or practice rather than
> absolutes; thus its hard for them to be objectively or "blatantly"
> wrong. Whether that's a good thing or not is another issue. I see the
> list as a starting point for discussion even if it does not settle
> everything.
>
> It brings up interesting questions, such as why not have schema
> inheritance? If inheritance is good or OO, why is it not good for
> relational schema's? The answer is that OO and relational approach
> things differently.

This reminds me of a serious 'click' moment I had with data structures. A long time ago, in a galaxy far far away, I once sat blindly reinventing my own network model, with identifiers, pointers, types, and all the fun of the fair. As an OO programmer it was the only mindset I had. Then I considered encoding data similar to the classic example of:

  • Aristotle is a man
  • All men are mortal
  • |= Aristotle is mortal

Well, /clearly/ what I was dealing with here was a generic entity class, of which Man was a subclass, and Aristotle an instance. Something like:

class Entity
{
boolean mortal;
string name;
Entity(_name, _mortal) : name(_name), mortal(_mortal); };

class Man : public Entity
{
date bday;
Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday); };

But, as I extended the example, the structures got more convoluted, and the result more and more of a mess. Finally something clicked. It wasn't about types, objects or inheritance, it was about /inference/, and what I actually had was:

Name(x, Aristotle) -> Species(x, Man)
Species(x, Man) -> Mortality(x, Mortal)
|= Name(x, Aristotle) -> Mortalilty(x, Mortal)

No types or reification in sight. Instead I had two groups of statements:
People = {Name, Species, Bday}
Entities = {Species, Mortality}

A join of the two statements gave me the inference I required: {Name, Mortality}. All of a sudden it seemed simple. So some questions:

  1. So why not treat all 'inheritance' in this way?
  2. Could one extend to include 'behaviour' as well?
  3. And is this a crazy thing to suggest in a cross post to an OO group?

>
> > The
> > problem with wikipedia is any ignorant fool can just start typing
> > nonsense. Even when one follows the requirements for references to
> > primary sources, the quality of the end product can vary over many
> > orders of magnitude.
>
> -T-
Received on Tue Mar 04 2008 - 00:06:05 CET

Original text of this message