Re: Clean Object Class Design -- What is it?

From: Bob Badour <bbadour_at_golden.net>
Date: Mon, 16 Jul 2001 00:48:43 -0400
Message-ID: <6uu47.55$YS3.20837431_at_radon.golden.net>


>> Relational databases store objects in table columns.
>
>I'm really intrigued by this turn of the thread. Perhaps you could point me
>to a commercial vendor or two who provides such a relational database that
>stores objects in table columns?

From what I hear, Lee Fesperman's all-java database does. I have also heard that later versions of Oracle do; although, I also heard that Oracle makes the mistake of allowing one to equate tables to object classes. I haven't directly verified either statement for myself so I cannot really say for sure.

>And by the way, from my OO 101 days, I believe one of the key attributes of
>an object is that it has identity.

An object variable has identity, but then again so do all variables. Object values are self-identifying, of course -- as are all values.

If you are going to use the term "object" unqualified (ie. not object class, object instance, object variable or object value), could you please define the term? The term gets such sloppy usage that it eventually becomes meaningless.

>Two instantiations of a class that have
>the same state (attribute values) are not the same object.

I agree: Of course, they are different "objects". More precisely, they are two distinct object variables that happen to have the same (object) value -- just as x and y can both have the value 10.0 without being the same variable.

>With the data
>copying inherent in all the relational systems of which I'm aware, how is
>this constraint maintained?

I am not sure what copying you refer to. I am not aware of any copying inherent to the logical data model; it would seem to me that copying is a physical operation and not a logical operation.

Candidate keys in conjunction with relation variable names and attribute names provide logical identity for individual object variables in the relational model.

>You may counter that the alternative is exposing pointers to "users"

I don't see how "identity" requires pointers when we have the option of candidate keys.

>if that "pointer" is no longer lived than the result table from a query,
 where's
>the harm?

As just one example, it provides no way to refer back to your original object from an excel spreadsheet.

>I don't expect my DBA to reorganize the physical layout of my table
>while I'm in the middle of using it.

Do you expect your database users to know how to identify the data they manipulate?

"novice guru" -- Catchy! I assume it's tongue-in-cheek. Received on Mon Jul 16 2001 - 06:48:43 CEST

Original text of this message