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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:VZq17.4148$u96.72897587_at_radon.golden.net...
> >For me an object model is much easier to understand than a
> >dozen of tables that are linked together.
>
> Dozens of object classes linked by a multitude of pointer types is easier
 to
> understand than a dozen tables associated by like values? You have to be
> kidding.
>

I hope you're not serious. Worrying about primary, foreign keys adds a level of complexity that object models don't have. Also, while the internal physical implementation of a UML association may end up being an OID, this is hidden from the user and doesn't mean you're suddenly dealing with "pointers." The OID is simply an existential key.

>
> >What's wrong with the approach?
>
> The data model.
>

The essence of this argument boils down to this:

"Because set theoretics are easier to comprehend than other formalisms, it must be superior."

It's a terrible argument. I know you're a fan of C.J. Date, but he's just too fanatical about this. The relational model is easier to understand, but it's also more rigid because it is constrained to set operations. This rigidity is a disadvantage in applications that require high-performance, but still want the advantages of a hidden physical model.

>
> That's not true. I have repeatedly stated that relational databases are
> object databases and that relational databases are extremely useful. More
> useful, in fact, than databases based on any other known data model.
>

Re: object databases ... not true. As I'm sure has been pointed out to you, the relational model simply manipulates sets of tuples using set theoretic operations. There is no concept in the model of "inheritence" ... a key property of the object-oriented model ... this must be simulated by flattening the hierarchy. However, this means that related child objects are now in separate relations, and cannot be easily manipulated without multiple SQL statements. For example, change the model year of all vehicles on the lot at dealership A, where the parent object class Vehicle has been subclassed into Sedan, Coupe, and SUV.

In the object-oriented approach, the Sedan, Coupe, and SUV all contain the attributes of Vehicle, but can still be accessed through a single container for the dealership. In the case of the relational model, these subclasses must be accessed in separate relations and updated in separate relations via at least three update statements.

Now if you want to argue that you could split the parent attributes out into a separate relation, that's fine, but then you've destroyed any pretense that a tuple = an object. Now you're just simulating object behavior just like it is often simulated in non-object-oriented languages like C.

>
> >Using insults, talking about the old-days 30-years-ago
>
> In the old days 30-years ago, I was six and I spent my summers chasing the
> Dickie-Dee cart [Dickie-Dee was and probably still is the local equivalent
> of Good Humor.] Object orientation was already two years old, but it
> probably never developed a taste for Nutty-Buddies or Drumstiks.
>
> Are you saying that object orientation is outmoded because of its age? I
 am
> having a little difficulty discovering your point.
>

I'm not sure why you have to be so nasty about things. All relational database operations can performed via a Turing machine. Is Turing the real father of relational theory, and therefore object-oriented thinking? Ummm ... no.

I think everyone universally agrees that object-oriented techniques as we know them today were developed in the mid/late 80's. Usual suspects are Coad/Yourdan, Rumbaugh et al, Booch, Jacobson.

>
> >turning
> >definitions like "network-model whatevers" around in circles
>
> Actually, comparing your product to a network model database is an insult
 to
> network model databases.
>

These scurrilous remarks do nothing to enhance your point. Quite the opposite.

>
> >does not change
> >the attitude of our users that like our system.
>
> There is no stopping the invincibly ignorant. -DT
>

I'm not sure how a broad-brushed ad hominem like this does anything to make your point either. Because people successfully use his product they are ignorant? I doubt that ... most users default to relational and have to make a conscious choice to select an OODBMS. They're probably the opposite of ignorant.

>
> >I don't know a better
> >proof-of-concept than a happy mail by a user that encourages me to
 continue
> >development.
>
> There's one born every minute. Until they outlaw it, you might as well
 make
> a quick buck.
>

Unlike Oracle marketing reps, who are all wonderful people interested only in the well-being of your company?

I primarily use relational databases, but recognize there are areas where an OODBMS is a better choice (especially embedded apps, where the OODBMS usually is faster and smaller). Limiting your usage to one database type is like limiting yourself to one programming language. It's not wise. Received on Sun Jul 22 2001 - 01:34:04 CEST