Re: Object-relational impedence

From: Bob Badour <>
Date: Wed, 05 Mar 2008 11:17:04 -0400
Message-ID: <47ceb976$0$4066$>

Leslie Sanford wrote:

> "JOG" wrote:

>>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
>>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
> I'm jumping in realizing that I may be revealing a bit of ignorance here, so
> bear with me.
> If I need to send a message to all persons who are mortal, I could join
> People and Entities together by species and where Mortality is true?
> Once I've performed the join, I then dispatch a message to the resulting
> group: "GetAnnualCheckUp()" or something?
> In the application I'm currently writing, I have a large list of parameters.
> These parameters share some values such as Name and Label. However, there
> are different types of parameters such as those that represent a boolean
> state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
> etc., and other types. My current approach is traditional OO, and that's to
> have a hierarchy of Parameter classes. I can then keep a list of
> heterogeneous parameters and treat them polymorphically. For example:
> params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
> params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
> // Set a parameter value. All raw parameter values are in the range
> // of [0, 1]. Each parameter class knows how to transform raw parameter
> // values in an appropriate way.
> params[parameterId].SetValue(value);
> And all works well.
> I'm trying to wrap my head around how I would approach this problem using
> what you've described above. I could have a table representing attributes
> common to all parameters. Then tables representing attributes specific to
> one parameter type or another. I could relate the tables via foreign keys?
> When I need to dispatch parameter changes, I could join the appropriate
> tables and change the appropriate values?
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.


Relationally, I would approach what you are doing almost exactly as you are now. The data type for parameter values would be a union type with sub-types as appropriate.

Whether one has a single base relation with all parameter types or one has a different base relation for each sub-type becomes almost moot. No matter which one chooses, one can have both using views. Either a restrict view to derive each sub-type relation from the single base relation or a single union view to derive the super-type relation from the individual sub-type base relations.

If this is a subject that interests you, I highly recommend Fabian Pascal's _Practical Issues in Database Management ..._ Received on Wed Mar 05 2008 - 16:17:04 CET

Original text of this message