Re: Object-relational impedence

On Mar 4, 12:47 am, "Leslie Sanford" <jabberdab..._at_bitemehotmail.com> 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
> > 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?
>
> 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?

Aye. Behaviour sits on top.

>
> 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.

If it works well don't touch it.

As if I need to tell you that.

>
> 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?

In your example all parameters had a name, and a value right? Well, then you'd have a set of {paramName, value} tuples, where you could update/insert values as necessary. (I'm assuming that we don't need paramID and the paramName attribute uniquely identifies each parameter).

In terms of other attributes recommended design would suggest a relation for 'floatAttributes', and one for 'selectionAttibutes'. They have different structures, and hence are collated under different predicates (with just the paramName again in common and functioning as a key). You'd join those to the values-relation as appropriate or necessary via the paramName key.

I imagine that sounds wacky as hell if you are not used to a relational approach, but there's no reason the functionality couldn't be built into a programming language (as opposed to sitting in an external db). As Codd showed in the 'great debate' it'd certainly simplify querying the data, compared to std::iterating like its 1999.

>
> 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.

Well, I'm talking theoretically atm - I'd certainly not abandon everything for mysql given your requirements... Received on Tue Mar 04 2008 - 02:47:42 CET