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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:5vw17.4167$xD2.77217972_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.
>
> I am very serious.
>

How unfortunate for you. Reading the rest of your response, I find it amusing. I'll respond appropriately, and then leave you to your fanatical funk.

>
> >Worrying about primary, foreign keys adds a
> >level of complexity that object models don't have.
>
> Object models use pointers which adds far more complexity.
>

An OID is a pointer? Okay, I guess keys are pointers too then.

>
> >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.
>
> An OID is a pointer. Hiding the "key" from the user makes things worse --
> not better.
>

No it doesn't, don't be ridiculous. Removing keys gets rid of a level of detail.

>
> >> >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."
>
> I did not say that at all. Please do not put words in my mouth. I am quite
> capable of doing that myself.
>

I'm sorry, that's precisely what you are saying. Chew carefully.

>
> >It's a terrible argument.
>
> Good thing it's not mine, then isn't it? Straw man.
>

It is your argument, deal with it.

>
> >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.
>
> You would prefer that it be constrained to navigation operations? Yuck!
 That
> would cripple the optimizer completely.
>

Interesting that it needs an optimizer to do simple navigation, don't you think? (I'm sure this point escapes you utterly, but hopefully the more cogent types reading this will understand)

>
> >This
> >rigidity is a disadvantage in applications that require high-performance,
> >but still want the advantages of a hidden physical model.
>
> The logical model is totally independent of the physical design rendering
> your above statement fatuous.
>

No, it's not. Unless you're prepared to argue that there are RDBMSs out there that store data in a manner similar to OODBMSs. I'm aware of none that do, so you're being fatuous. Once again, a typical non-response.

>
> >> 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.
>
> Since a tuple is a set of object instances, I think that clearly makes
> relational databases object databases. Wouldn't you agree?
>

Ah yes, echoing the fine words of C.J. Date: "relvar != object class" ... but that's an academic exercise, and it's given him some real heartburn when it comes to dealing with inheritance. In the meantime, the world has moved along and decided relvar = object class, even though we do see a few O-R databases with some complex domain types. Unfortunately, as Date will tell you, the execution of this new approach allows for ... gasp ... pointers, and he calls it a major blunder. I agree with him.

So you can argue until you're blue in the face about the academics of things, but here in practice, tuples get treated as a bunch of attributes. But they don't work very well as full-up objects.

>
> >There is no concept in the model of "inheritence"
>
> Says who?
>

C.J. Date. Says it right on the first page of The Third Manifesto. I don't believe anyone ever satisfactorily supplied a definition of "inheritance" to him so it could be tackled. Next?

>
> >... a key
> >property of the object-oriented model
>
> Says who?
>

Everyone but you. Next?

(If you need an education, go read Rumbaugh et al, Booch, Coad/Yourdan, etc. ... certainly stronger authorities on the subject than yourself ... might also help if you'd read Design Patterns by Gamma et al so you'd understand why inheritance combined with polymorphism is a key feature of the model)

>
> >... this must be simulated by
> >flattening the hierarchy.
>
> Here you are making the mistake of mapping objects to tables instead of
> domains as the relational model does.
>

Okay, let's take back that "mistake" I made. How does that solve this problem?

>
> >However, this means that related child objects
> >are now in separate relations, and cannot be easily manipulated without
> >multiple SQL statements.
>
> This statement is based on a false assumption, which renders it invalid.
>

Typical non-response. Of course it's valid, you just can't wiggle out of the problem.

>
> >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.
>
> I am astounded that you think the model year of an existing vehicle on the
> lot can change. Can we roll back the mileage while we are at it?
>

Typical non-response. If it bothers you so much, change the dealership name on the vehicle. Make the class names/attributes arbitrary. Of course, that might
involve answering the problem ... so maybe you should continue to skirt the issue.

>
> >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.
>
> Again, this whole paragraph is based on a false assumption, which renders
 it
> entirely irrelevant.
>

Again, you're just skirting around the nasty little problem of doing inheritance using the relational model. You've not supplied a single suggestion as to how it can be done.

>
> >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.
>
> I never had any pretense that a tuple = an object. A tuple is a set of
> object instances, which renders your whole argument invalid.
>

No, it doesn't. Saying that domains = classes doesn't solve this problem. Next?

>
> >> >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.
>
> Nasty about what?
>

Hmmm...right.

>
> >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.
>
> I guess you don't include me in your universe. One could likewise argue
 that
> the relational model has evolved over that period too. The relational
 model
> as I know it today is only a few months old.
>

Well, if it's that fluid then I guess it suffers from the same lack of definition that the object-model suffers from. Fortunately, I reject your assertion that it changes that much, and assert instead it's about as old as set theory (100 years or 2400 years depending on where you want to start). In terms of databases, it's clearly ~30 years old (EF Codd), and hasn't changed in any significant manner since then. In my opinion, The Third Manifesto was more of a "reinterpretation and clarification" than an "addition" to the model.

>
> >> >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.
>
> If I were selling a network model database, lumping my product in with
> Carl's would offend me.
>

How does this enhance your point? Is this "proof by insult?"

>
> >> >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?
>
> Define successful. If the happy users are ignorant of the actual costs and
> the vendor is ignorant of the unhappy users...
>
>
> >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.
>
> Not that I've seen. All of the folks I've met who consiously chose a
> non-relational OODBMS did so on the basis of misconception and ignorance.
>

I'm in the process of converting a user from an OODBMS to an RDBMS. The OODBMS works like a champ, but it's more economical to distribute the system bundled with a small, cheap RDBMS. Like I say, right tool for the right job.

I doubt you know any OODBMS users, based on your ignorance demonstrated here. On the other hand, I know of over a dozen OODBMS users, and most converted
out of RDBMS systems (due to speed problems). Many of those "ignorant" users
spent a fortune on RDBMS consultants before trying something new.

>
> >> >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?
>
> Oracle is the database equivalent of The Borg. Don't get me started...
>

Substitute Sybase, IBM DB2, or any other high-pressure salesdroid. Really doesn't matter, but let's not pretend that RDBMS companies are pure as the driven snow and OODBMS companies are the root of all evil.

>
> >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.
>
>
> I would agree that footprint trumps optimizer complexity for embedded
> applications. On the other hand, I have used some extremely
 small-footprint
> relational databases that have surprisingly good optimizers.
>

Optimizers don't beat direct access navigation, but that's a nice try. Received on Sun Jul 22 2001 - 01:34:16 CEST